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:
- Sauvegardes - les plugins innodb sont excellents et tout, mais les temps de sauvegarde sur autant de données ne sont tout simplement pas pratiques
- 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
- 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)
- 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:
- 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.
- 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.
- 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.
- 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.