Comment faire pour exécuter une grande mise à jour sur une base de données en direct?

Question

Un projet web que je suis en train de coder utilise un convertisseur complexe CSV en MySQL pour créer leur base de données. Cela signifie que pour mettre à jour le contenu db avec les dernières modifications des CSV, un convertisseur est exécuté qui tronque les tables pertinentes (mais en laisse d'autres qui sont remplies via le site Web) et les remplit à nouveau avec les données CSV.

Oui, ce n'est pas un très bon processus, mais il y a de bonnes raisons pour lesquelles cette approche a été choisie par rapport à une approche standard «travailler sur la base réelle». Ce qui me pose problème, c'est de trouver la meilleure façon d'exécuter ce processus de mise à jour sans trop nuire à l'expérience de l'utilisateur. Quelques chiffres à garder à l'esprit:

1) Ce processus doit être exécuté régulièrement, dans la gamme de quelques semaines/une fois par mois
2) Le convertisseur db prend actuellement environ une heure et sera probablement prendre 3) Le vidage sql de la base de données complète est actuellement inférieur à 20MB (ce qui permet une importation facile via phpmyadmin), mais il se cassera à 15h dans le futur, au moins si les prédictions sur la croissance de la base de données sont correctes (oui, aïe!) cette barrière assez tôt. Je suppose que cela ne devrait pas être un problème car je peux simplement utiliser le téléchargement SSH à la place.

Voici quelques-unes des alternatives auxquelles je pensais, toutes utilisant une base de données séparée avec des paramètres globaux (ces paramètres sont vérifiés pour chaque lecture/écriture sur le site). L'alternative 2 semble être la pire car elle empêche l'accès en lecture pendant tout le temps de la conversion, ce qui peut être assez long comme je l'ai dit. Tous bloquent l'accès en écriture pour à peu près le même temps, ce qui est correct, cela n'empêche pas les utilisateurs de s'inscrire ou quelque chose de critique comme ça. Je suis assez curieux de savoir si la troisième option est faisable car elle permet théoriquement de réduire les temps d'arrêt de la fonctionnalité de lecture car je n'ai pas besoin de télécharger une grosse image.

Est-ce que quelqu'un a fait quelque chose comme ça? J'apprécie des solutions de rechange supérieures si elles sont là-bas ou des commentaires sur la façon d'améliorer ces derniers et si de choisir 1 ou 3. Merci d'avance :)

Alternative 1
1) Set globalsettings_booleans_writeable to 0
2) Download current DB (SQL dump)
3) Import downloaded DB locally
4) Run converter (in update mode) on local database
5) Export local DB
6) Set globalsettings_booleans_readable to 0
7) Import exported DB online
8) Set globalsettings_booleans_readable to 1
9) Set globalsettings_booleans_writeable to 1

Alternative 2
1) Set globalsettings_booleans_writeable to 0
2) Set globalsettings_booleans_readable to 0
3) Run converter (in update mode) on live database
4) Set globalsettings_booleans_readable to 1
5) Set globalsettings_booleans_writeable to 1

Alternative 3
1) Set globalsettings_booleans_writeable to 0
2) Create a remote copy of the database
3) Run converter (in update mode) on remote copy
4) Set globalsettings_booleans_readable to 0
5) Replace remote original with remote copy (easy?)
6) Set globalsettings_booleans_readable to 1
7) Set globalsettings_booleans_writeable to 1

Answer 1

Il me semble que beaucoup d'exclusivité pourrait être évitée en examinant le fichier CSV pour voir quels enregistrements entraîneraient une modification de la base de données. Il semble que le générateur CSV soit la source réelle des données, et la base de données est simplement un miroir, n'est-ce pas? Si tel est le cas, les enregistrements CSV qui n'aboutissent à aucun changement peuvent être ignorés, les tables d/b non tronquées et les enregistrements CSV restants peuvent être exécutés en utilisant l'alternative 2, ce qui ne prendra vraisemblablement que quelques minutes.

La principale faiblesse de cette approche est si les enregistrements sont supprimés à la source et il n'y a aucune indication que le d/b doit être supprimé localement.