Quelles pratiques ou quels outils permettent le déploiement continu des bases de données?

La livraison continue ou le déploiement continu de l'infrastructure et du code est relativement simple par rapport à l'essai des mêmes approches pour les bases de données, en particulier les SGBDR. Le code et l'infrastructure ne changeront ni n'évolueront une fois le déploiement terminé. Cependant, de nouvelles données seront ajoutées aux bases de données, ce qui rendra les données sinon les composants intrinsèquement mutables du schéma.

Je suis conscient qu'il existe des pratiques telles que l'ajout uniquement d'objets de base de données, c'est-à-dire des tables et des colonnes, sans jamais les modifier ou les supprimer - cette façon purement additive d'approcher les schémas de base de données a l'avantage de garantir que les schémas sont rétrocompatibles au prix de plus en plus compliqués. schémas.

Il existe également des produits tels que Flyway et Ready Roll qui aident à écrire les migrations à écrire entre les versions d'un schéma.

Quelles autres pratiques et outils existent actuellement pour permettre le déploiement continu des schémas de base de données dans un environnement de production où l'intégrité des données est une préoccupation?

Pramod Sadalage et Scott Ambler ont écrit un livre Refactoring Databases: Evolutionary Database Design qui est une introduction incroyablement solide au sujet des bases de données dans une organisation / équipe de CD.

Les défis

Je suis conscient qu'il existe des pratiques telles que l'ajout uniquement d'objets de base de données, c'est-à-dire des tables et des colonnes, sans jamais les modifier ou les supprimer

Dans une entreprise pour laquelle je travaillais, une fenêtre mobile de données brutes équivalait à environ 6 mois et consommait jusqu'à 10 To. Les données ont ensuite été traitées dans un format SGBDR qui a coûté 6 To de données utilisables, ce qui représentait environ 10 ans de données à déclarer. Le fait étant qu'à grande échelle, ce genre de pratiques n'est tout simplement pas pratique. Le stockage coûte cher - probablement la plus grosse dépense de calcul. Cela présente plusieurs défis intéressants:

1. Sauvegardes - les plugins innodb sont excellents et tout, mais les temps de sauvegarde sur autant de données ne sont tout simplement pas pratiques
2. Temps de restauration - pour les grands ensembles de données - en particulier si vous avez besoin d'une réplication pour rattraper le retard après une restauration, le retour à un état opérationnel peut prendre des jours, voire des semaines
3. Création / amorçage de nouvelles instances - Souvent, le travail que vous effectuez dans le développement / test implique des travaux ETL (Extraire, Transformer et Charger) sur votre jeu de données. Ceux-ci doivent être validés à l'aide d'unités de test d'AQ, mais cela doit être fait de manière non destructive afin que l'ensemble de données de production d'origine soit préservé. En cas de sinistre, vous pouvez être prêt à faire face à une longue période de restauration en sachant que les sauvegardes sont une police d'assurance et que l'intention est de les éviter, le flux de travail de développement DevOps nécessite essentiellement que vous puissiez effectuer une restauration ou une copie de vos données sur une base régulière (peut-être plusieurs fois par jour)
4. Capacité - élingage autour de ces données beaucoup à l'échelle que je viens de décrire peut être très E / S intensive. Non seulement vous devez résoudre les problèmes décrits en 1-3, mais vous devez le faire de manière à ne pas provoquer de pannes ou de ralentissements des performances de vos systèmes de production.

Bien que les considérations ci-dessus ne soient pas une préoccupation à des échelles plus petites, à des échelles plus grandes, elles deviennent d'énormes problèmes. Cela signifie qu'il est extrêmement important de définir vos besoins et de prévoir la taille de votre ensemble de données.

Définition des exigences

Par conséquent, vous devez définir plusieurs exigences:

1. RTO - RTO ou Restore Time Objective pour les sauvegardes sont l'un des pilotes les plus importants des solutions de sauvegarde de base de données. Alors qu'au début, il peut ne pas sembler pertinent pour la plupart des autres problèmes, il devient extrêmement pertinent lorsque vous demandez "Et si j'utilisais ma solution de sauvegarde pour créer ou amorcer de nouvelles instances?". Je vais couvrir quelques techniques pour le faire dans la section suivante.
2. RPO - RPO ou Restore Point Objective for backups définit A) dans quelle mesure vous pouvez restaurer (minutes, heures, jours, semaines, mois ou années) B) L'intervalle de sauvegarde à différents niveaux et C) dans quelle mesure vous pouvez restaurer . Par exemple, pour les bases de données de courrier électronique, les sauvegardes au niveau du message - restauration d'un courrier électronique spécifique - sont souvent recherchées. De même, vous pouvez constater que les données sur quelques jours sont complètement inutiles - il est donc inutile de restaurer une année en arrière.
3. Taille de votre ensemble de données - Ceci est important car pour une base de données de 1 Mo, votre RTO peut être atteint avec la plupart des produits et solutions de sauvegarde. Cependant, pour une base de données de 10 To, vous constaterez qu'une sauvegarde complète de niveau ligne sur bande LTO 3 n'atteindra probablement pas votre RTO et pourrait interférer avec votre RPO car les sauvegardes commencent à dépasser votre fenêtre de sauvegarde. Vous ne pouvez pas exactement faire juste un mysqldump sur ce grand ensemble de données, mais vous pourriez probablement vous en sortir avec la base de données de 1 Mo.
4. Cohérence de la base de données - Une dernière chose qui fait une énorme différence dans le déploiement continu, la fiabilité du site, l'évolutivité et la haute disponibilité lorsque vous travaillez avec des bases de données est votre besoin (ou son absence) de cohérence. Il existe trois types de base: cohérence immédiate, cohérence juste à temps (JIT) et cohérence éventuelle

Outre les principales considérations ci-dessus, vous devez également prendre en compte les exigences de licence et de support (open source ou source fermée; support interne, support tiers ou support fournisseur) les exigences de la langue / application (les connecteurs de nombreuses bases de données peuvent être importants; est votre application compilée? Avez-vous accès au code source? Pouvez-vous le recompiler, ou est-il fourni par un fournisseur? Ou s'exécute-t-il dans un langage interprété?) Exigences politiques (votre organisation fait-elle uniquement confiance à Oracle? ? Ne font-ils pas confiance à MySql? Que pensez-vous de MariaDB ou Postgres?) Et du moteur de base de données (innoDB? MyISAM? Blackhole? NDB Cluster? Spider?) Et des exigences historiques ou de compatibilité (nous avons utilisé PL / SQL pendant des années et la moitié de notre code est intégré dans le moteur Oracle! Comment pourrions-nous jamais porter sur MariaDB?!?)

Toutes ces choses ont un impact (significatif) sur les outils à votre disposition.

Quelques options pour la gestion interne des données

Remarque: ce qui suit n'est en aucun cas exhaustif, et les autres utilisateurs de SE devraient apporter des suggestions supplémentaires.

Avec les considérations génériques à l'écart, permettez-moi de vous fournir quelques techniques et technologies pour répondre à ce qui précède. Tout d'abord, demandez-vous si vous avez vraiment besoin d'utiliser un SGBDR ou si des données non structurées avec quelque chose comme Hadoop, CouchDB ou même un stockage orienté objet (quelque chose comme swift) est une option.

Deuxièmement, envisagez d'étudier une solution basée sur le cloud. Cela sous-traite une partie de ce mal de tête et laisse les problèmes compliqués à des individus hautement qualifiés (et rémunérés). À grande échelle cependant, vous pouvez trouver que cela mange vraiment dans votre budget (les fournisseurs de cloud font un profit à cela, et à une certaine échelle, vous pouvez simplement vous permettre d'employer ces experts vous-même), ou si vous travaillez sous une sécurité spécifique ou politique exigences (lire: nous ne pouvons pas faire de nuages) envisager un Filer hybride NFS / FibreChannel. La plupart de ces fichiers, tels que ceux de NetApp, Pure Storage et Tegile, prennent en charge une technique de cliché et de clonage basée sur le delta qui peut être très pratique pour A) prendre des sauvegardes, B) restaurer des sauvegardes et C) semer de nouvelles sauvegardes.

À ce stade, je dois noter que je ne suis pas un expert de la sauvegarde et du stockage, il y a donc certaines parties de ce problème que je n'ai jamais pu résoudre avant de passer à d'autres problèmes (et à des pâturages plus verts).

Cela étant dit, ces produits vous permettent de prendre des instantanés différentiels sous votre base de données. Vous devrez créer un script complet de «tables de verrouillage avec verrouillage en lecture» sur l'une de vos instances de base de données (un esclave en lecture seule est recommandé) et vider votre position de journal des connexions ou GTID, mais pour ces fichiers, une fois que vous le ferez, vous pourrez d'utiliser ces snaps pour créer de nouvelles instances de votre base de données. Vous souhaiterez mettre des journaux de transactions sur une partition séparée et ne mettre que vos données de base de données sur ces partitions. Une fois que vous le ferez, vous pourrez cloner ces partitions (sur NetApps, ceci est connu comme un " FlexClone "

En effet, pour chaque bloc lu, le déclarant doit déterminer si les données résident dans l'instantané d'origine figé ou dans le delta. Pour les volumes / magasins avec plusieurs instantanés, cela peut devoir être vérifié plusieurs fois. Vous pouvez surmonter cela en actualisant les données (c'est-à-dire en supprimant votre instantané et en le clonant de nouveau périodiquement - ce qui peut se produire naturellement et de manière organique pour un bon environnement de déploiement continu) ou en fractionnant de façon permanente le volume (connu sous le nom de "Flex Split" dans la terminologie NetApp ), ce qui prendra un moment pour résoudre définitivement les deltas et créer un volume entièrement nouveau et séparé.

Ces clones delta ont l'avantage supplémentaire de réduire vos besoins de stockage globaux - vous pouvez générer plusieurs clones ou instances de vos données de base de données de production pour effectuer votre développement, vos tests et votre validation. Si vous ne conservez qu'une seule copie de votre grand ensemble de données plus les (ce qui est susceptible d'être) de petits deltas, vous réduisez votre coût de stockage global et votre empreinte.

La seule astuce ici est que cela ne peut pas constituer une solution de sauvegarde complète car la "sauvegarde" réside toujours sur votre filer. Pour cela, vous devrez peut-être utiliser quelque chose que NetApp appelle un miroir instantané qui reflétera les données (en utilisant la technologie de style rsync) entre les filers et même les centres de données, ou utiliser un type de solution de sauvegarde intégrée qui peut sauvegarder sur bande l'un de vos instantanés delta ou un flex-clone.

Cependant, cela a un défaut majeur: toutes vos données - dev, test et prod utilisent toujours des E / S sur le même filer et la même tête de stockage. Pour contourner ce problème, envisagez de créer une instance de base de données esclave sur un deuxième filer qui peut être le point de départ pour votre testeur et / ou dev filer, ou envisagez d'utiliser un équilibreur de charge / contrôleur de livraison d'applcation pour votre couche d'application pour refléter les demandes de production dans votre environnement (s) de test (et / ou de développement). Cela a l'avantage supplémentaire de générer du trafic de production vers votre environnement QA / Test avant de passer à la production pour des problèmes qui pourraient ne pas être immédiatement détectés. Vous pouvez ensuite vérifier vos journaux pour les erreurs en fonction du trafic de production et du comportement des utilisateurs.

Cela devrait alors vous permettre d'utiliser quelques scripts pour générer et détruire par programme des ensembles de données entiers (et volumineux) à utiliser avec les méthodologies de déploiement continu.

Évolutivité et haute disponibilité

Alors que vous avez posé des questions sur le déploiement continu, DevOps ne se limite pas au déploiement continu - je vais donc inclure quelques éléments sur la redondance, l'évolutivité et la haute disponibilité.

J'ai mentionné, JIT, la cohérence immédiate et éventuelle. C'est là que divers moteurs RDBMS entrent en jeu. La cohérence finale est relativement facile en configurant simplement la réplication asynchrone circulaire. Cela peut cependant provoquer des collisions * (et si votre couche d'application met à jour les données d'un côté du cluster et de l'autre côté du cluster avant la fin de la réplication?) Pour une cohérence immédiate, regardez le cluster Galera qui forcera la réplication synchrone, mais provoque des problèmes d'évolutivité (comment allez-vous répliquer sur votre site de récupération après sinistre ou équilibrer la charge géographiquement sans encourir de latence importante en raison d'un retard de propagation au niveau de la couche réseau?) Vous pouvez également voir si vous pouvez effectuer une réplication synchrone dans le centre de données et une réplication asynchrone entre sites, mais cela semble le pire des deux mondes.

Cependant, la plupart des utilisateurs n'ont pas besoin de réplication entièrement synchrone - cela n'est généralement nécessaire que pour les environnements à écriture élevée très spécifiques (et exotiques) où le multi-maître est nécessaire avec le partage de table. La plupart des applications peuvent gérer la cohérence Just-In-Time à l'aide d'un proxy de base de données. Par exemple, ScaleArc surveillera le statut de la réplication et suivra où les écritures se sont déroulées (pour envoyer des demandes de lecture subquentes jusqu'à ce que la réplication rattrape) pour fournir une cohérence juste à temps et l' apparencede cohérence de la base de données. ScaleArc est compatible avec Postgres, MySQL, MariaDB, Oracle et MSSQL et peut utiliser des expressions régulières pour partager / partitionner vos bases de données pour des applications qui ne peuvent pas utiliser de clés de partition. Il dispose également d'une API REST robuste pour interagir avec votre logiciel de gestion de configuration - et leur équipe de support est exceptionnelle

De même, vous souhaiterez peut-être envisager une alternative gratuite, MaxScale développée par l'équipe MariaDB pour MariaDB. Il manque cependant l'interface graphique et certaines des fonctionnalités de mise en cache de ScaleArc.

Enfin, la structure MySQL (et le cluster MySQL en RAM uniquement - si vous pouvez vous permettre autant de RAM) sont d'autres potentiels - en particulier avec le nouveau proxy de MySQL. Cela peut fournir le composant d'évolutivité et de redondance à votre environnement.

Postgres et Oracle devraient avoir les fonctionnalités de réplication et de partitionnement dont vous avez besoin, mais ScaleArc s'associera bien si vous avez besoin d'un proxy.

En fin de compte, tous ces éléments s'ajoutent à un environnement très flexible adapté au déploiement et au développement continus si vous ne pouvez pas simplement utiliser un environnement cloud et laissez votre fournisseur de cloud gérer les problèmes ci-dessus pour vous.

Nous utilisons Flyway au travail pour gérer les schémas Postgres dans l'application et Pillar pour gérer les schémas Cassandra. Nous l'avons mieux trouvé si l'application gère son propre schéma.

Nous avons eu une expérience horrible d'avoir des schémas de gestion ansible avant que les applications ne gèrent leurs propres schémas.

Je dirais qu'un outil seul ne sera pas vraiment utile à moins que vous ne transfériez la responsabilité du schéma à l'équipe d'application.

Nous utilisons la base de données ou la voie de migration au travail, où l'équipe d'application est responsable de la création des changesets.

Parallèlement à cela, vous pouvez éviter une manière purement additive.
Chaque application doit être compatible avec sa version précédente, lorsqu'une modification du schéma doit être effectuée, l'application intègre alors une nouvelle colonne dans le schéma, y ​​écrit et lit et écrit toujours de / vers la colonne précédente (permettant la version précédente pour conserver les mêmes données).
La prochaine version de l'application est autorisée à arrêter la mise à jour de l'ancienne colonne et seule la troisième version sera autorisée à supprimer la colonne désormais inutilisée.

De toute évidence, des sauvegardes régulières sont nécessaires en cas de problème.
Un bon sous-ensemble de données susceptible de créer des problèmes dans les tests d'intégration pour les éviter en production est également une bonne idée. Dans le cas idéal, obtenez un sous-ensemble anonyme de données de production.

Nous utilisons la base de données dans notre travail et j'en serai très reconnaissant . Il est également utilisé par notre outil QA QASymphony .

Nous l'utilisons contre les bases de données MSSQL et Oracle en interne et QASymphony l'utilise / l'a utilisé avec les deux instances postgres + mysql.

Pour répondre à cette question dans le contexte d'un environnement mainframe et spécifique aux bases de données DB2, il existe généralement 2 alternatives couramment utilisées (pas bon marché ...) parmi lesquelles choisir:

• Administration d'objets pour DB2 , à partir de BMC. Voici quelques détails à ce sujet (citation de la page liée):

  Apporter des modifications aux objets de votre base de données - ou même simplement effectuer des tâches administratives de routine - peut être un travail difficile et risqué. Il y a des dizaines de tâches à suivre, et un seul faux pas pourrait avoir un impact désastreux sur la disponibilité et l'intégrité des données. Vous pouvez réduire les efforts et les risques avec BMC Object Administration pour DB2 11, une collection d'outils pour vous aider:

  • Réduisez le temps requis pour administrer des environnements DB2 complexes et disparates.
  • Automatisez les tâches de routine tout au long du cycle de vie de l'application pour une meilleure intégrité.
  • Améliorez la productivité avec la navigation simplifiée dans le catalogue DB2 et la gestion des modifications.
  • Améliorez la disponibilité des applications en effectuant des modifications et une maintenance avec un minimum de pannes.

• Outil d'administration DB2 pour z / OS , d'IBM.

  Il simplifie les tâches complexes associées à la gestion sécurisée des objets et du schéma DB2 tout au long du cycle de vie de l'application avec le moins d'impact possible sur la disponibilité.

  • Permet aux utilisateurs de naviguer rapidement et facilement dans le catalogue DB2
  • Construit et exécute des instructions SQL dynamiques sans connaître la syntaxe SQL exacte
  • Gère et suit les modifications apportées aux définitions d'objet DB2, résolvant tout conflit potentiel avant l'exécution
  • Aide à créer des commandes DB2 à exécuter sur des bases de données et des tables
  • Permet aux utilisateurs de créer, de modifier, de migrer, de supprimer et de désosser des objets DB2
  • Construit et exécute des tâches utilitaires, permettant aux utilisateurs de profiter des LISTDEF et des MODELES pour une productivité accrue

Intégration avec les outils SCM

Il y a quelque temps, un client m'a mis au défi d'intégrer réellement l'alternative BMC dans leur cycle de vie SCM (géré par SERENA ChangeMan ZMF ). L'idée derrière une telle intégration étant " Considérez notre équipe DB2 DBA (faire des trucs avec des DDL) comme un cas particulier d'une équipe de développement, utilisant accidentellement un éditeur exotique (l'outil BMC) pour produire le code (DDL) à migrer ".

Le seul défi (mais réel !) De cette intégration était également de faciliter la "redémarrabilité", qui est l'un des principaux avantages d'un tel outil DBA:

• La possibilité de redémarrage signifie que lorsque cet outil DBA fait son travail (via des travaux parfois longs, selon la nature du travail à effectuer), des choses inattendues peuvent se produire (blocages, temporisations, etc.).

• Si l'une de ces choses se produit et que vous ne voulez pas redémarrer à partir de votre sauvegarde (avant de commencer), l'outil DBA s'attend à ce que vous redémarriez à partir du point (check-) à partir duquel les choses ont commencé à mal tourner (et d'où vous voulez que tout soit réexécuté).

• Mieux encore (ou devrais-je dire "encore pire"?), Si un nouvel utilisateur de l'outil DBA ne sait pas vraiment comment redémarrer à partir d'un tel point de contrôle, et essaie simplement à nouveau (depuis le début), alors l'outil DBA échouera simplement avec une sorte d'erreur utilisateur. Et ceci avec une indication avec quelque chose comme " Jusqu'à ce que vous me disiez comment vous voulez que je procède après mon dernier point d'échec, je refuse de faire quoi que ce soit (pour ne pas aggraver les choses) ".

• En fin de compte, le véritable indice pour implémenter cette possibilité de redémarrage dans l'outil SCM utilisé, nécessitait que l'outil SCM soit également réglé. En fait, pour lui permettre d'être utilisé pour redémarrer les procédures SCM échouées (généralement liées aux livraisons aux environnements de test / prod cibles) ... au lieu de simplement soumettre la procédure SCM échouée à nouveau (ce qui est généralement la façon dont ces outils SCM récupèrent de telles situations ).

Bonus: une fois l'intégration SCM de l'alternative BMC terminée, le client a décidé de remplacer son outil DBA par l'alternative IBM. Et même si les deux alternatives ne se ressemblent pas vraiment, leur impact sur l'intégration SCM était plutôt minime: il s'agissait simplement de remplacer (dans certaines personnalisations SCM réutilisables) certains appels à l'alternative BMC par des appels équivalents à IBM alternative ... qui (en utilisant la terminologie DevOps) a été implémentée par des drapeaux de fonction / bascule de fonction .