Quelles sont les pratiques que vous suivez pour éviter les mises à jour de données erronées dans les grandes bases de données?


20

Un conseil typique avant tout déploiement de production est de sauvegarder la base de données en premier. De cette façon, si la nouvelle mise à jour présente un problème qui peut entraîner une perte de données potentielle ou une corruption des données logiques, vous disposez toujours d'une sauvegarde pour comparer et corriger les anciens enregistrements.

Cependant, cela peut bien fonctionner jusqu'à ce que la taille de la base de données soit de quelques Go. Une fois que la taille de la base de données est énorme, les sauvegardes prennent beaucoup de temps. Quelles sont les meilleures pratiques à suivre dans de telles situations, afin d'éviter la corruption des données logiques en raison de problèmes logiques dans un déploiement de code?


11
Les sauvegardes ne sont pas uniquement destinées aux déploiements. Je veux dire, votre perte de données n'est qu'à un crash de disque, et celles-ci sont imprévisibles et peuvent se produire aujourd'hui ou demain. (Les tableaux de raid ne sont pas la réponse, ils plantent également.)
Pieter B

10
Je reformulerais cette question, le problème n'est pas que les sauvegardes prennent beaucoup de temps, le problème est que dans le cas où une mise à jour a un échec désastreux, une restauration peut devenir nécessaire, ce qui peut bloquer la production pendant une longue période. Donc, ce que vous recherchez vraiment, c'est une stratégie pour atténuer les risques d'échec lors d'une mise à jour.
Doc Brown du

1
Je suis d'accord avec @DocBrown ici. Éviter la corruption des données et les sauvegardes prenant trop de temps sont vraiment deux questions distinctes.
Robbie Dee

1
Lorsque vous acceptez rapidement, vous n'obtenez pas autant d'informations.
paparazzo

1
Que voulez-vous dire par "problèmes logiques dans un déploiement de code"?
paparazzo

Réponses:


25

En tant que personne qui s'occupe régulièrement de la mise à jour de la base de données de production pour les clients pour nos mises à niveau logicielles, je vous dis que la meilleure façon de minimiser les erreurs est de faire des mises à jour aussi simples que possible.

Si vous pouvez effectuer une modification sur tous les enregistrements plutôt que sur des enregistrements spécifiques, il est préférable.

En d'autres termes, si vous recevez une liste d'ID d'enregistrements dont l'état doit être modifié, vous devez vous demander pourquoi la mise à jour est effectuée dans le contexte du programme. Il peut s'agir des 10 enregistrements que vous devez mettre à jour, le tableau ne contient que 10 éléments. Par conséquent, vous devez vous demander si, conceptuellement, tout ce que vous faites est de mettre à jour l'état de tous les enregistrements.

Si vous pouvez insérer, c'est préférable.

L'acte d'ajouter un enregistrement est autonome. J'entends par là qu'il n'y a qu'un seul effet secondaire de l'ajout d'un enregistrement, et c'est l'existence d'un enregistrement qui n'existait pas auparavant. Par conséquent, à moins que vous n'ajoutiez un enregistrement qui ne devrait pas y figurer, il ne devrait y avoir aucun problème.

Si vous pouvez éviter la suppression, il est préférable.

Si vous effectuez une suppression, vous supprimez des données qui seraient autrement irrécupérables sans sauvegarde. Si possible, essayez d'organiser les données de manière à pouvoir désactiver les enregistrements en modifiant son état plutôt qu'en supprimant physiquement l'enregistrement. L'excédent de données peut être placé dans une partition ou il peut être entièrement supprimé plus tard une fois que vous êtes sûr qu'il n'y a pas de problème.

Ayez une politique de mise à jour cohérente.

Si vous devez mettre à jour un enregistrement, plusieurs choses peuvent se produire:

  1. Votre dossier n'existe pas.
  2. Votre dossier existe mais il a déjà été modifié.
  3. Votre dossier existe et nécessite la modification.

Vous devez avoir une politique pour déterminer la marche à suivre si quelque chose ne se passe pas comme prévu. Par souci de simplicité, vous devez être cohérent dans tous les domaines et appliquer cette stratégie dans toutes les situations de ce type, et pas seulement pour des tableaux spécifiques. Cela facilite la récupération ultérieure des données. Généralement, ma politique est d'écrire le script de manière à pouvoir le ré-exécuter plus tard. En cas d'échec du script, il est bon de savoir que vous pouvez effectuer les ajustements appropriés et réexécuter, mais vous êtes libre de choisir votre propre politique qui vous convient le mieux.

Sauvegardes

Cela ne vous excuse en aucun cas d'effectuer une sauvegarde avant d'effectuer une mise à jour dans un environnement de production! Bien que même avec une sauvegarde, je considère que c'est un échec d'avoir à utiliser la sauvegarde. La perte de données ne peut pas être une possibilité, même dans le pire des cas .

Conclusion

Tu ne vas pas toujours pouvoir l'avoir à ta façon. Le schéma de table ne sera probablement pas déterminé par vous, et en tant que tel, cela signifie que les types de mises à jour que vous pouvez vous attendre à effectuer seront à la fois compliqués et risqués. Bien que si vous avez un mot à dire sur la question, il est utile de garder ces points à l'esprit car ils effectuent des mises à jour directement et sans risque significatif.

Bonne chance!


Je suis d'accord avec tout ce que vous avez dit, mais j'étais curieux de savoir ce que vous pensez des transactions lorsqu'il y a 10 enregistrements qui doivent être changés sur 10k et que les insertions / mises à jour de tous les enregistrements ne sont pas viables?
Je suis là pour Winter Hats le

Il vous suffit ensuite de mettre à jour les 10 enregistrements. J'ai dit que si tu peux, fais-le. Je n'ai pas dit de le faire même s'il détruit la base de données de production de votre client. Suivez mes conseils avec un grain de sel s'il vous plaît.
Neil

12

À ce stade, vous devez utiliser un système DB de qualité commerciale qui prend en charge les instantanés (Oracles l'appelle Flashback ) - c'est exactement le genre de chose à laquelle ils sont destinés.

Gardez à l'esprit que vous avez besoin d'un concept de sauvegarde de toute façon - avoir plus de données ne signifie pas que vous supprimez les sauvegardes car elles deviennent difficiles, bien au contraire. Vous avez besoin d'une sorte de sauvegarde continue, par exemple basée sur la réplication avec basculement automatique.


Je ne dis pas que je veux abandonner les sauvegardes. Les sauvegardes planifiées sont toujours là. La question concerne davantage les sauvegardes ad hoc, qui ne sont pas un problème pour les petits systèmes.
Pritam Barhate,

Pour aller plus loin, cette réflexion est venue des plates-formes NoSQL DB as Service. En fait, je lisais la documentation Firestore, quand elle est apparue. Si vous avez besoin de sauvegardes logiques cohérentes hors site, cela semble très coûteux. Je me demandais donc comment les équipes de produits performantes fonctionnent avec de tels systèmes et comment elles garantissent qu'aucune corruption logique des données ne se produit.
Pritam Barhate, du

@PritamBarhate: vous n'avez pas besoin de "plus de sauvegardes" à cause des mises à jour. Sur une base de données de production où les gens travaillent avec ces données, les sauvegardes doivent être effectuées au moins quotidiennement, avec ou sans mises à jour. Les restaurations sont votre problème, vous voulez éviter les restaurations inutiles en toutes circonstances.
Doc Brown du

3
La réplication avec basculement automatique est que la redondance n'est pas plus une stratégie de sauvegarde pour les bases de données que l' utilisation du RAID pour les disques .
Blrfl

1
Tous les bons points sur les sauvegardes et les instantanés, mais le nettoyage d'une opération de base de données bâclée (si plusieurs heures de nouvelles données ont été ajoutées avant leur réalisation) peut être très difficile en fonction du scénario et des autres systèmes qu'il affecte (planificateurs, autres entrées de base de données qui en dépendent, s’il s’étend sur plusieurs tables, caches, authentifications, etc.). Je suppose toujours que je vais devoir utiliser une sauvegarde, mais essaie toujours au moins de ne jamais avoir à le faire.
Anonymous Penguin

3

C'est un domaine énorme - alors attendez-vous à ce que cette question soit fermée dans un délai assez court, mais, du haut de ma tête (en tant qu'ancien DBA sur d'énormes bases de données):

Mart / Dépôt

Vous pouvez atténuer certains risques si vous disposez d'une base de données distincte pour les mises à jour et d'une base de données distincte que tout le monde utilise. Ensuite, il s'agit simplement de copier les données d'un DB à l'autre une fois que diverses vérifications ont été effectuées. Mart / repository est la façon dont il est parfois décrit, mais vous pouvez avoir primaire / secondaire, maître / esclave, etc.

Code source

Pour tout ce qui peut changer, ayez un code source qui explique comment les données ont été mises à jour. Le nombre de ceux-ci varie d'une base de données à l'autre, mais vous pouvez en avoir un pour chaque utilisateur, rôle, flux de données, module de code, etc.

Date de création / mise à jour

La création et la mise à jour des données pour chaque ligne peuvent être très utiles lors du suivi des problèmes. Ensuite, vous pouvez voir d'un coup d'œil quelles lignes ont été mises à jour.

ETL

Si la mise à jour de la base de données fait partie d'une fabrique de données, vous pourrez peut-être restaurer un millésime précédent à partir de fichiers plats.

Sauvegarde

Les sauvegardes complètes prennent bien sûr beaucoup d'espace mais le scénario habituel est qu'une sauvegarde complète se produise à intervalles réguliers (dit, hebdomadaire) et partielles sur une base plus fréquente (quotidienne, etc.).

Récupération ponctuelle

Selon le SGBDR que vous utilisez, certains points de support prennent en charge la récupération dans le temps. Cela vous permet de revenir à l'époque où un bon état était connu. Cela nécessite cependant une grande quantité de stockage qui augmente en fonction de la distance que vous souhaitez parcourir.

Audit

Les tables d'audit vous diront qui (ou quoi) a mis à jour une ligne. Cela peut vous donner un bon point de départ pour une enquête.

Histoire

Pour certaines tables critiques, une copie de la ligne pertinente est prise au moment de la mise à jour afin que les données puissent être restaurées si nécessaire.

La validation des données

Assurez-vous que les contrôles de validation de base sont effectués sur les données avant leur stockage - en plus des contrôles de type de données de base.

Intégrité référentielle

L'intégrité référentielle n'est pas une solution miracle, mais elle peut aider à garantir que les données sont bien structurées.



2

Plusieurs fois, si nous effectuons une mise à jour "en une fois", nous prenons une sauvegarde de la production et la restaurons sur un serveur de test. Ensuite, nous créons une combinaison de tests et exécutons le one shot. Nous vérifions que les données ont changé via les tests et nous nous assurons que cette mise à jour réussira et modifions les données d'une manière que nous attendons. C'est ce qu'on appelle un essai à sec ou d'essai. Je recommande de faire ça.

Cela donne à tout le monde un bon sens que le one shot réussira. Nous ne pouvons pas garantir 100% car les données seront mises à jour à partir de la date de l'essai, mais nous renforçons la confiance et les facteurs de réussite. Cela donne également une vraie idée de tous les problèmes qui se produiront puisque nous utilisons une copie de la production. Maintenant, si pour une raison quelconque, la mise à jour échoue, nous pouvons toujours passer à la version précédente avant de restaurer si nécessaire, mais nous aurions dû trouver et corriger tout problème avec la version sèche.

Si vous ne pouvez pas prendre l'intégralité de la base de données (si elle est vraiment volumineuse), essayez d'exporter une taille d'échantillon plus petite et exécutez la mise à jour (petite analyse à sec) par rapport aux données réelles. Je préférerais l'ensemble des données si possible pour garantir que le test est aussi complet que possible.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.