🤕 👸🏻 👩‍🔧 Livre «Bases de données. Ingénierie de la fiabilité 👰🏾 😳 🤚🏻

Bonjour, habrozhiteli! Dans le domaine de l'informatique, une véritable révolution a eu lieu - ils ont commencé à travailler avec l'infrastructure comme avec le code. Ce processus crée non seulement de nouveaux problèmes, mais aussi des opportunités pour garantir la disponibilité des bases de données. Les auteurs ont préparé ce guide pratique pour quiconque souhaite rejoindre la communauté des ingénieurs modernes de fiabilité des bases de données (DBRE).

Dans ce livre: • exigences de stockage et exigences de gestion des risques. • Création et développement d'une architecture qui fournit un support de base de données transparent. • rationaliser le processus de gestion des versions. • stockage, indexation et réplication des données. • déterminer les caractéristiques de l'entrepôt de données et sélectionner les meilleures options pour son utilisation. • recherche de composants d'architecture et création d'architectures orientées vers le traitement des mégadonnées.

Pour qui est ce livre?

, , . , . , . , , . .

, Linux/Unix, - / . , — — — . , , .

, , , . , , .

, , . , - , . , Excel, .

Structure de publication

. . , , , . : , , , . , . !

, : (DBRE), (RE). , . DBR- , , .

, . . , . — , . , , , , , , , . .
, .

1 . , — , DBRE, — , , DBRE .

2 . , . , , — , . , .
3 . . .

4 . . , , . , .

5 6 . . , , , , , .

7 . , , DBE. — , . , , , .

8 . , ? SQL? — , .

9 . . .

10 , . , , . , .

11 . , , . , , , .

12 (), , , . , « » () , , . — .

, 13 . , .

Restauration de sauvegarde

Dans les chapitres 5 et 6, nous nous sommes concentrés sur la conception et la gestion des infrastructures. Cela signifie que vous avez une bonne idée de la façon de créer et de déployer des infrastructures distribuées dans lesquelles les bases de données fonctionnent, ainsi que de les gérer. Nous avons examiné les méthodes permettant d'ajouter rapidement de nouveaux nœuds pour augmenter la capacité ou remplacer un nœud défaillant. Il est maintenant temps de discuter de la chose la plus importante - la sauvegarde et la restauration des données.

Avouons-le: tout le monde envisage de sauvegarder et de restaurer des activités ennuyeuses et fastidieuses. Pour la plupart, ces procédures sont la quintessence de la routine. L'équipe n'aime pas interagir avec les ingénieurs débutants et les entrepreneurs externes et travailler avec des outils tiers. Avant, nous devions gérer un logiciel de sauvegarde horrible. Nous sympathisons avec vous, honnêtement.

Néanmoins, c'est l'un des processus les plus importants de votre travail. Le déplacement de données importantes entre des nœuds, des centres de données et leur transfert vers des archives à long terme est un mouvement constant de l'actif le plus précieux de votre entreprise: les informations. Nous vous recommandons fortement de ne pas considérer les opérations de récupération et de sauvegarde comme des opérations de seconde classe, mais de les traiter comme des opérations VIP. Tout le monde doit non seulement comprendre les objectifs de la récupération de données, mais également être familiarisé avec les principes de ce travail et de la surveillance des processus. La philosophie DevOps suppose que tout le monde devrait pouvoir écrire du code et l'implémenter dans un système vraiment fonctionnel. Nous invitons chaque ingénieur à participer au moins une fois aux processus critiques de récupération de données.

Nous créons et stockons des copies de données - sauvegardes et archives - afin de répondre à un besoin spécifique. Ils sont nécessaires à la récupération. Parfois, la récupération est une affaire agréable et tranquille, par exemple lors de la création d'un environnement pour les auditeurs ou de la création d'un environnement alternatif. Mais le plus souvent, il est nécessaire de remplacer rapidement les nœuds défaillants ou d'augmenter la capacité des clusters existants.

Aujourd'hui, dans les environnements distribués, nous sommes confrontés à de nouveaux défis dans la sauvegarde et la récupération de données. Comme précédemment, la plupart des ensembles de données locaux sont distribués dans des limites raisonnables, jusqu'à quelques téraoctets maximum. La différence est que ces ensembles de données locaux ne sont qu'une partie d'un grand ensemble distribué. La récupération de site est un processus relativement contrôlé, mais le maintien de l'état dans un cluster est une tâche plus difficile.

Principes de base

Nous commençons par discuter des principes de base de la sauvegarde et de la récupération des données. Pour un spécialiste de base de données ou un ingénieur système expérimenté, certains d'entre eux peuvent sembler élémentaires. Si c'est le cas, vous pouvez facilement faire défiler plusieurs pages.

Physique ou logique?

Une sauvegarde physique de la base de données sauvegarde les vrais fichiers dans lesquels les données sont stockées. Cela signifie que les formats de fichiers typiques de la base de données sont pris en charge, et il y a généralement un ensemble de métadonnées dans la base de données qui détermine quels sont les fichiers et quelles structures de base de données s'y trouvent. Si, lors de la création de copies de sauvegarde de fichiers, vous vous attendez à ce qu'une autre instance de base de données puisse les utiliser, vous devrez effectuer une sauvegarde et enregistrer les métadonnées qui lui sont associées, sur lesquelles cette base de données s'appuie, afin que la sauvegarde soit portable.

Lors de la création d'une sauvegarde logique, les données sont exportées de la base de données vers un format qui peut théoriquement être transféré vers n'importe quel système. Habituellement, les métadonnées sont également enregistrées, mais elles seront probablement pertinentes pour le moment où la sauvegarde a été effectuée. Un exemple est l'exportation de toutes les instructions d'insertion nécessaires pour remplir une base de données vide lors de sa mise à jour. Un autre exemple est une chaîne JSON. En conséquence, les sauvegardes logiques, en règle générale, prennent beaucoup de temps, car il ne s'agit pas d'une opération de copie et d'écriture physique, mais d'une extraction de données ligne par ligne. De même, la récupération s'accompagne de tous les frais généraux de base de données habituels, tels que le verrouillage et la création de journaux de rétablissement et d'annulation.

Un bon exemple de cette séparation est la distinction entre la réplication basée sur les lignes et la réplication basée sur les instructions. Dans de nombreuses bases de données relationnelles, la réplication basée sur l'agent signifie qu'après avoir écrit dans le système de contrôle de version, un journal des opérateurs du langage de manipulation de données (DML, ou insérer, mettre à jour, remplacer, supprimer) leur est ajouté. Ces déclarations sont transmises aux répliques dans lesquelles elles sont diffusées. Une autre approche de la réplication est basée sur des chaînes ou sur Change Data Capture (CDC).

Autonome ou opérationnel?

Une sauvegarde hors ligne (ou à froid) est une sauvegarde dans laquelle l'instance de base de données utilisant les fichiers est désactivée. Grâce à cela, vous pouvez copier rapidement des fichiers sans vous soucier du maintien de l'état pour le moment, tandis que d'autres processus lisent et écrivent des données. C'est une condition idéale, mais très rare.

Avec une sauvegarde en ligne (ou à chaud), vous copiez toujours tous les fichiers, mais il y a une complexité supplémentaire associée à la nécessité d'obtenir un instantané cohérent des données, qui doit exister au moment où la sauvegarde est effectuée. De plus, si le trafic actuel accède à la base de données pendant la sauvegarde, vous devez veiller à ne pas dépasser le débit du sous-système d'E / S au niveau du stockage. Même en limitant la charge, vous pouvez constater que les mécanismes utilisés pour maintenir la cohérence introduisent des retards déraisonnables dans l'application.

Complet, incrémentiel et différentiel

Une sauvegarde complète, quelle que soit la méthode de création, signifie que l'ensemble de données local est entièrement réservé. Pour les petits jeux de données, c'est assez courant. Pour 10 To, cela peut prendre un temps incroyable.

Les sauvegardes différentielles vous permettent de sauvegarder uniquement les données qui ont changé depuis la dernière sauvegarde complète. Mais en pratique, plus de données sont généralement sauvegardées que simplement les données modifiées, car les données sont organisées sous la forme de structures d'une certaine taille - des pages. La taille de la page est par exemple de 16 ou 64 Ko et la page contient de nombreuses lignes de données. Les sauvegardes différentielles sauvegardent toutes les pages sur lesquelles les données ont été modifiées. Ainsi, avec de grandes tailles de page, des sauvegardes d'une taille beaucoup plus grande sont obtenues que si seules des données modifiées y étaient stockées.

Les sauvegardes incrémentielles sont similaires aux sauvegardes différentielles, sauf que la date de la dernière sauvegarde à laquelle les données modifiées se réfèrent est incrémentielle ou complète. Ainsi, lors de la restauration à partir d'une sauvegarde incrémentielle, vous devrez peut-être restaurer la dernière sauvegarde complète, ainsi qu'une ou plusieurs sauvegardes incrémentielles, pour arriver au point actuel.

Sachant cela, nous discuterons de plusieurs points qui devraient être pris en compte lors du choix d'une stratégie de sauvegarde et de récupération de données efficace.

Considérations sur la récupération des données

Lorsque vous choisissez une stratégie efficace pour la première fois, vous devez à nouveau tenir compte de vos objectifs de qualité de service (SLO), qui ont été examinés au chapitre 2. En particulier, vous devez tenir compte des indicateurs de disponibilité et de fiabilité. Quelle que soit la stratégie que vous choisissez à la fin, elle devrait toujours inclure la possibilité de récupérer des données dans les limites prédéfinies de disponibilité. Et vous devrez sauvegarder rapidement pour garantir le respect de vos spécifications de fiabilité.

Si vous sauvegardez tous les jours et conservez les journaux de transactions entre les sauvegardes en stockage au niveau du site, vous pouvez facilement perdre ces transactions jusqu'à la prochaine sauvegarde.

En outre, vous devez considérer le fonctionnement de l'ensemble de données au sein d'un écosystème holistique. Par exemple, vos commandes peuvent être stockées dans une base de données relationnelle, où tout est fixé sous forme de transactions et, par conséquent, peuvent être facilement restaurées par rapport à d'autres données stockées dans cette base de données. Cependant, une fois la commande formée, le workflow peut être déclenché par un événement stocké dans le système de file d'attente ou un stockage de type "valeur-clé". Ces systèmes ne peuvent garantir l'intégrité des données qu'occasionnellement ou même brièvement (pour être éphémères), en se référant, si nécessaire, à la base de données relationnelle ou en l'utilisant pour la récupération. Comment prendre en compte ces workflows lors de la récupération?

Si vous avez affaire à un environnement où un développement rapide est en cours, il peut s’avérer que les données stockées dans la sauvegarde ont été écrites et utilisées par une version de l’application et qu’une fois la restauration effectuée, une autre est exécutée. Comment l'application interagira-t-elle avec les données obsolètes? Eh bien, si les données sont versionnées - alors cela peut être pris en compte, mais vous devez être conscient de cette possibilité et être prêt à de tels cas. Sinon, l'application peut logiquement endommager ces données, ce qui entraînera des problèmes encore plus importants à l'avenir.

Toutes ces nuances et bien d'autres qui ne peuvent être prédites doivent être prises en compte lors de la planification de la récupération des données. Comme indiqué au chapitre 3, il est impossible de se préparer à toute situation. Mais c'est très important d'essayer de le faire. La récupération des données est l'une des tâches les plus importantes d'un ingénieur pour assurer la fiabilité de la base de données. Ainsi, votre plan de récupération de données doit être aussi large que possible et prendre en compte autant de problèmes potentiels que possible.

Scénarios de récupération

Après avoir pris en compte tout ce qui précède, nous discuterons des types d'incidents et d'opérations qui peuvent nécessiter une récupération de données afin que tous les besoins puissent être planifiés. Tout d'abord, vous pouvez diviser tous les scénarios en planifiés et non planifiés. En considérant la récupération de données uniquement comme un outil de résolution des urgences, vous limitez les outils de votre équipe aux seuls soins d'urgence et simulez les accidents. À l'inverse, si la récupération de données est incluse dans les activités quotidiennes, un degré plus élevé de sensibilisation et une résolution réussie des urgences peuvent être attendus. De plus, nous disposerons de plus de données pour déterminer si la stratégie de récupération prend en charge nos SLO. Avec quelques exécutions quotidiennes du script, il sera plus facile d'obtenir un ensemble d'échantillons,qui comprend des valeurs limites et qui peut être utilisé en toute confiance pour la planification.

Scénarios de récupération planifiée

Dans quelles tâches quotidiennes les processus de restauration peuvent-ils s'intégrer? Voici la liste que nous avons rencontrée le plus souvent sur différents sites:

la création de nouveaux nœuds et grappes dans un environnement d'exploitation industrielle;
création d'environnements divers;
effectuer l'extraction, la transformation et le chargement (extraire, transformer et charger, ETL) et les étapes du processus technologique de traitement des données pour les stockages placés séquentiellement;
Test de performance.

Lorsque vous effectuez ces opérations, veillez à inclure le processus de récupération sur la pile de contrôle opérationnel. Tenez compte des indicateurs suivants.

Temps. Combien de temps faut-il pour terminer chaque composant et l'ensemble du processus? Déballage? Copie? Exécution du journal? Essai?
La taille. Combien d'espace prend une sauvegarde, compressée et non compressée?
. ?

Ces informations vous aideront à éviter les problèmes de bande passante, ce qui contribuera à garantir la stabilité du processus de récupération.

Nouveaux nœuds et grappes dans un environnement d'exploitation industriel

Que vos bases de données fassent partie d'une infrastructure immuable ou non, il existe des possibilités de reconstructions régulières, dans lesquelles des procédures de récupération seront utilisées si nécessaire.

Les bases de données sont rarement incluses dans la mise à l'échelle automatique des systèmes en raison du temps qui peut être nécessaire pour le chargement initial d'un nouveau nœud et son placement dans un cluster. Néanmoins, aucune raison n'empêche l'équipe de créer un calendrier d'ajout régulier de nouveaux nœuds au cluster pour tester ces processus. Chaos Monkey ( http://bit.ly/2zy1qsE) - un outil développé par Netflix qui arrête les systèmes de manière aléatoire, vous permet de le faire de manière à pouvoir tester l'ensemble du processus de surveillance, d'émission de notifications, de tri et de restauration. Si vous ne l'avez pas déjà fait, vous pouvez l'inclure dans le plan de la liste de contrôle des processus que votre service d'exploitation doit effectuer à intervalles réguliers afin que tous les employés se familiarisent avec la procédure. Ces actions vous permettent de tester non seulement la récupération complète et incrémentielle, mais également l'inclusion de la réplication et le processus de mise en service du nœud.

Créez des environnements différents

Vous créerez inévitablement des environnements de développement, d'intégration et de tests opérationnels à des fins de démonstration et à d'autres fins. Certains de ces environnements nécessitent une récupération complète des données et ils doivent implémenter la récupération des nœuds et la récupération complète des clusters. Certains environnements ont d'autres exigences, telles que la prise en charge de la récupération partielle pour le test des fonctionnalités et le nettoyage des données pour garantir la confidentialité des utilisateurs. Cela vous permet de tester la récupération de données à un moment précis, ainsi que la récupération d'objets spécifiques. Tout cela est très différent de la récupération complète standard et est utile pour réparer les dommages causés par les actions de l'opérateur et les erreurs d'application. En créant une API,qui assurent la récupération des données au niveau de l'installation et à un moment précis, vous pouvez faciliter l'automatisation et la familiarisation des employés avec ces processus.

Processus ETL et de pipeline pour les entrepôts de données situés plus loin dans le pipeline

Comme pour les tâches de création d'un environnement, les processus et les API de récupération à partir d'instantanés ou au niveau d'objets individuels peuvent être appliqués avec succès lors du transfert de données de bases de données de travail vers des pipelines pour une analyse plus approfondie et un stockage en continu .

Test sur le terrain

Pendant l'exécution de divers scénarios de test, vous aurez besoin de copies des données. Certains tests, par exemple pour la capacité et la charge, nécessitent un ensemble complet de données, ce qui est idéal pour une récupération complète. Les tests fonctionnels peuvent nécessiter des ensembles de données plus petits, ce qui permettra la récupération à un moment précis et au niveau de l'installation.

Les tests de récupération de données eux-mêmes peuvent être une opération continue. En plus d'utiliser des processus de récupération de données dans des scénarios quotidiens, vous pouvez configurer des opérations de récupération continue. Cela automatisera les tests et la validation afin d'identifier rapidement tout problème pouvant survenir si le processus de sauvegarde est interrompu. Quand il s'agit de mettre en œuvre ce processus, beaucoup demandent comment vérifier le succès d'une récupération.

Lors de la création d'une sauvegarde, vous pouvez obtenir un grand nombre de données que vous pouvez ensuite utiliser pour les tests, par exemple:

L'identifiant le plus récent de la séquence d'incrémentation automatique
compteur de lignes pour les objets;
des sommes de contrôle pour des sous-ensembles de données qui sont uniquement insérés et peuvent donc être considérés comme immuables;
sommes de contrôle dans les fichiers de définition de schéma.

Comme pour tout test, l'approche doit être à plusieurs niveaux. Il existe un certain nombre de tests qui réussiront ou échoueront rapidement. Cela devrait être le premier niveau de test. Les exemples sont la comparaison des sommes de contrôle pour les définitions de métadonnées / objets, le démarrage réussi d'une instance de base de données et la connexion réussie à un flux de réplication. Les opérations qui peuvent prendre plus de temps, telles que le calcul des sommes de contrôle et le comptage des tables, doivent être effectuées plus tard au cours de la vérification.

Scripts imprévus

Compte tenu de tous les scénarios planifiés quotidiens pouvant être utilisés, le processus de récupération des données doit être bien débogué, documenté, élaboré et suffisamment exempt d'erreurs et de problèmes. Grâce à cela, les scénarios imprévus s'avèrent rarement aussi effrayants qu'ils pourraient l'être. L'équipe ne doit pas voir la différence entre une récupération planifiée et non planifiée. Nous listons et considérons en détail les situations qui peuvent nous obliger à effectuer des processus de récupération:

erreur utilisateur
erreur d'application;
disponibilité des services d'infrastructure;
les erreurs du système d'exploitation et les erreurs matérielles;
pannes matérielles;
défaillances du centre de données.

Erreur utilisateur Idéalement, les erreurs utilisateur devraient rarement se produire. En construisant une «balustrade» et une «barrière» pour les ingénieurs, vous pouvez éviter bon nombre de ces situations. Cependant, il est toujours possible que l'opérateur provoque accidentellement des dommages. Un exemple typique est la clause WHERE partout et pour tous oubliée lors de l'exécution de UPDATE ou DELETE dans une application cliente de base de données. Ou, par exemple, l'exécution du script de nettoyage des données ne se fait pas dans un environnement de test, mais dans un système de "production" fonctionnel. Souvent, l'opération est effectuée correctement, mais au mauvais moment ou non pour ces hôtes. Tout cela concerne les erreurs de l'utilisateur. Souvent, ils sont identifiés et corrigés immédiatement. Cependant, les conséquences de tels changements passent parfois inaperçues pendant plusieurs jours ou semaines.

Erreurs d'application

Les erreurs d'application sont les pires des scénarios discutés, car elles peuvent être très insidieuses. Les applications changent constamment la façon dont elles interagissent avec les entrepôts de données. De nombreuses applications gèrent également l'intégrité référentielle et les pointeurs externes vers des ressources telles que des fichiers ou des identifiants tiers. Il est effrayant d’imaginer ce qui se passera si vous apportez une modification qui gâche les données, les supprime ou ajoute des données incorrectes de manière à passer inaperçue pendant un certain temps.

Services d'infrastructure

Au chapitre 6, nous avons présenté la magie des services de gestion d'infrastructure. Malheureusement, ces systèmes peuvent s'avérer aussi destructeurs qu'utiles, ce qui peut entraîner des conséquences à grande échelle liées à la modification d'un fichier, à un autre environnement ou à des paramètres de configuration incorrects.

Erreurs du système d'exploitation et erreurs matérielles

Les systèmes d'exploitation et les équipements avec lesquels ils interagissent sont également des systèmes créés par des personnes, ce qui peut entraîner des erreurs qui peuvent avoir des conséquences inattendues en raison de configurations non documentées ou mal connues. Dans le contexte de la récupération de données, cela est particulièrement vrai en ce qui concerne la façon dont les données sont transférées de la base de données via des caches de système d'exploitation vers des systèmes de fichiers, des contrôleurs et éventuellement vers des disques. Les dommages ou la perte de données se produisent beaucoup plus souvent que nous ne le pensons. Malheureusement, notre confiance et notre confiance dans ces mécanismes font naître des attentes d'intégrité des données plutôt que de scepticisme à leur sujet.

Netflix 2008 . (ECC). ECC . , ECC- , , . , 46 512- 92 . , , , « » S.M.A.R.T. 92 . . , ?

. , , . , . — .

, ZFS, , . RAID-, , .

Défaillances

matérielles Les composants matériels échouent en principe, et dans les systèmes distribués, cela se produit régulièrement. Vous rencontrez constamment des pannes de disque, de mémoire, de processeur, de contrôleur et de périphérique réseau. Les conséquences de ces défaillances matérielles peuvent être la défaillance de nœuds ou des retards sur les nœuds, ce qui rend le système inutilisable. Les systèmes partagés, tels que les périphériques réseau, peuvent influencer des clusters entiers, les rendant inaccessibles ou les diviser en clusters plus petits qui ne savent pas que le réseau a été divisé. Cela peut entraîner des écarts rapides et importants dans les données qui doivent être combinées et corrigées.

Échecs du centre de données

Parfois, des problèmes matériels au niveau du réseau entraînent des plantages dans le centre de données. Il arrive que la surcharge des fonds de panier de stockage entraîne des échecs en cascade, comme ce fut le cas avec les services Web Amazon en 2012 ( http://bit.ly/2zxSpzR ). Parfois, des ouragans, des tremblements de terre et d'autres catastrophes entraînent la défaillance de centres de données entiers. La récupération ultérieure testera même les stratégies de récupération les plus fiables pour la résistance.

Portée du script

Après avoir énuméré les scénarios planifiés et non planifiés qui peuvent nécessiter une récupération, nous ajoutons une dimension supplémentaire à ces événements afin que notre présentation devienne volumineuse. Cela sera utile pour choisir la méthode de réponse la plus appropriée. Considérez les options suivantes:

panne localisée dans un seul nœud;
échec de l'ensemble du cluster;
Une défaillance qui affecte l'ensemble du centre de données ou plusieurs clusters.

En cas d'échec local ou unique, la récupération est limitée à un hôte. Vous pouvez ajouter un nouveau nœud au cluster pour augmenter la capacité ou remplacer un nœud défaillant. Ou bien, le système met en œuvre une mise à jour continue, puis la restauration sera effectuée nœud par nœud. Dans tous les cas, il s'agit d'une récupération locale.

Au niveau du cluster, le besoin de récupération est global pour tous les membres de ce cluster. Peut-être y a-t-il eu un changement destructif ou une suppression de données qui se sont répercutées en cascade sur tous les nœuds. Ou vous devez introduire un nouveau cluster pour tester la capacité.

S'il y a eu une panne à l'échelle du datacenter ou de plusieurs clusters, cela signifie qu'il est nécessaire de restaurer toutes les données à l'endroit de leur emplacement physique ou dans toute la zone de panne. Cela peut être dû à une défaillance de l'entrepôt de données partagé ou à une défaillance qui a provoqué une défaillance catastrophique du centre de données. Une telle récupération peut également être nécessaire lors du déploiement prévu d'un nouveau site secondaire.

En plus de l'étendue, il existe une étendue d'ensemble de données. Ici, vous pouvez lister trois options possibles:

un objet;
plusieurs objets;
métadonnées de la base de données.

À l'échelle d'un objet, seul cet objet particulier nécessite une récupération de données - une partie ou la totalité. Le cas discuté précédemment, à la suite duquel, lorsque l'opération DELETE a été effectuée, plus de données ont été supprimées que prévu, fait référence à une défaillance au sein du même objet. Si plusieurs objets échouent, plusieurs ou, éventuellement, tous les objets d'une base de données particulière sont affectés. Cela peut se produire si l'application est endommagée, la mise à jour ou la migration de segment échoue. Enfin, il y a des plantages à l'échelle des métadonnées de la base de données lorsque tout est en ordre avec les données stockées dans la base de données, mais les métadonnées sont perdues ce qui les rend utilisables, telles que les données utilisateur, les privilèges de sécurité ou la conformité avec les fichiers du système d'exploitation.

Conséquences du script

Il est important non seulement d'identifier le scénario nécessitant une récupération et d'identifier la zone de défaillance, mais également de déterminer les conséquences possibles, car elles seront importantes lors du choix d'une approche de récupération. Si la perte de données n'affecte pas SLO, vous pouvez choisir une approche méthodique et lente qui minimise l'expansion des conséquences. Les changements plus globaux qui conduisent à la perturbation de SLO doivent être abordés avec prudence, en choisissant une récupération de service rapide et en passant ensuite à un nettoyage à long terme. Toutes les approches peuvent être divisées en trois catégories suivantes.

L'impact sur SLO, l'échec de l'application, a affecté la plupart des utilisateurs.
Menace SLO, certains utilisateurs en ont souffert.
Les fonctions ne menaçant pas SLO sont affectées.

À propos des auteurs

Campbell Lane (Laine Campbell) est cadre supérieur (directeur principal) pour la société de conception Fastly. Elle a également été fondatrice et PDG de PalominoDB / Blackbird, un service de conseil qui gère des bases de données pour plusieurs sociétés, dont Obama pour l'Amérique, Activision Call of Duty, Adobe Echosign, Technorati, Livejournal et Zendesk. Elle possède 18 ans d'expérience dans l'exploitation de bases de données et de systèmes distribués évolutifs.

Cherity Majors(Charity Majors) est le PDG et co-fondateur de honeycomb.io. Combinant la précision des agrégateurs de journaux, les métriques de vitesse des séries chronologiques et la flexibilité des métriques de performance des applications (APM), Honeycomb est le premier service analytique véritablement de nouvelle génération au monde. Cheriti était auparavant spécialiste des opérations Parse / Facebook, gérant une énorme flotte de jeux de répliques MongoDB, ainsi que Redis, Cassandra et MySQL. Elle a également travaillé en étroite collaboration avec l'équipe RocksDB sur Facebook, participant au développement et au déploiement de la première installation Mongo + Rocks au monde à l'aide de l'API de plug-in de stockage.

»Vous trouverez plus d'informations sur le livre sur le site Web de l'éditeur
» Sommaire
» Extrait

Pour Khabrozhiteley 25% de réduction sur le coupon - Bases de données

Lors du paiement de la version papier du livre, un livre électronique est envoyé par e-mail.

Livre «Bases de données. Ingénierie de la fiabilité