MySQL Synchronisation entre 1 base locale et distante

[KoRnMuse]

Bonjour à tous,

J'ai créé un site assez basique en PHP/MySQL sur lequel j'interviens régulièrement pour ajouter des fonctionnalités ou du contenu.

J'utilise Wamp pour le développement et j'ai un hébergement mutualisé chez OVH pour la production.

Actuellement, j'exporte manuellement les tables de ma base de donnée afin de les importer sur le serveur distant en utilisant phpMyAdmin.

Je suis obligé de vider les tables sur mon serveur distant afin de ne pas avoir d'erreur lors de l'importation (logique, vu que certaines données existent déjà...) voire de modifier manuellement la structure de mes tables avant importation (lorsque j'ai rajouté une colonne par exemple).
Bref, c'est loin d'être pratique et c'est souvent long et fastidieux.

Ma question : Y a t'il un moyen simple de mettre à jour toute ou une partie de la base de donnée sans avoir à faire toutes ces manipulations ?

Je suis autodidacte et je ne suis pas expert en MySQL donc j'imagine qu'il doit bien y avoir une fonctionnalité/astuce pour faire ça plus proprement et rapidement.

Je ne peux à priori pas utiliser la synchronisation/replication du fait que je n'ai pas accès à toutes les fonctionnalités de phpMyAdmin sur mon hébergement mutualisé.

La solution la plus simple serait de pouvoir exporter/importer les tables comme je le fais actuellement, mais que les tables soient automatiquement complètement écrasées au niveau structure et données lors de l'importation.

Merci d'avance.

[BreizFenrir]

Le mieux serait effectivement que tout ça soit automatisé, mais vu la manière dont tu sembles travailler à l'heure actuelle et le fait que tu utilises un hébergement mutualisé qui ne permet pas un accès direct vers le serveur de base de données, ça risque d'être compliqué.

On peut déjà dans un premier temps voir comment gérer ça proprement "à la main" (i.e. en rédigeant des scripts de migration de schéma et d'import/modification pour les données existantes). Ca dépend après de la taille de ta base et de la quantité de donnée, mais ça ne sera pas pire que de perdre les données... Je vais supposer que la volumétrie n'est pas énorme, et que tu ne changes pas le schéma de ta base du tout au tout à chaque déploiement.

Il faudrait que tu maintiennes lorsque tu fais des modifications un document SQL avec ce qu'il faut de requêtes pour passer de la version N-1 de ta base à la version N. Comme ça, à chaque mise-à-jour, tu ne déploiera que la différence entre la base existante et ce que tu veux obtenir. La bonne chose, c'est que MySQL dispose d'une documentation relativement complète et assez claire. Je vais y faire référence par la suite.

Pour tout retrait, ajout de colonne ou en général modification de la structure d'une table existante, si tu ne veux pas le faire en cliquant partout sur phpMyAdmin (ce qui peut rester le plus simple si tu n'es pas très à l'aise avec SQL), il faut utiliser la commande ALTER TABLE.

Pour l'insertion de nouvelles données, utilise la commande INSERT comme tu le fais déjà. N'hésites pas à reprendre le fichier généré par l'export à partir de ton environnement de développement, en supprimant tous les tuples correspondants à des données qui existent déjà si c'est plus simple pour toi.

Pour la modification de données existantes, ça sera la commande UPDATE. Utile aussi quand tu ajoutes des colonnes mais que tu ne souhaites pas que les anciens enregistrements utilisent la valeur par défaut.

L'avantage d'un tel fichier, c'est qu'au moment du déploiement tu fais copier/coller de son contenu dans le champ de soumission de requête de phpMyAdmin, tu valides et c'est bon (à moins qu'il n'y ait des erreurs dans le script SQL). L'inconvénient, c'est que ça fonctionne bien quand tu n'as que des manipulations simples à faire, et que tu ne manipules que poignée de tables et d'enregistrements.

Ne pas oublier en tout cas avant toute mise à jour de faire une sauvegarde de l'état de la base de données, que tu peux utiliser pour remettre le site en état si la mise-à-jour se passe mal.

Enfin, plutôt que devoir aller soumettre ce genre de commandes à la main dans phpMyAdmin, ça pourrait aussi être du code PHP spécifique qui pilote la mise-à-jour, de sorte que celle-ci pourrait se faire en déployant les fichiers en environnement de production suivi d'une visite à http://monSite.fr/update.php. Dans ce genre de cas, il vaut mieux s'assurer que l'opération de mise-à-jour ne foute pas la base en l'air si on l'exécute une seconde fois (ce qui a très très peu de chance d'arriver, le script SQL aurait plutôt tendance à s'arrêter en erreur sur la première commande en général).

[RFN]

Bonsoir,

La solution la plus simple serait de pouvoir exporter/importer les tables comme je le fais actuellement, mais que les tables soient automatiquement complètement écrasées au niveau structure et données lors de l'importation.

Tu peux exporter ta base via phpMyAdmin avec l'option "Vider la table avant d'insérer". Ensuite à l'importation, le script virera les données pour mettre celle de la base exporter.

Bien sur, cela implique la perte des données modifiées dans la base cible...

[KoRnMuse]

Merci pour votre réponse à tous les deux.

Le mieux serait effectivement que tout ça soit automatisé, mais vu la manière dont tu sembles travailler à l'heure actuelle et le fait que tu utilises un hébergement mutualisé qui ne permet pas un accès direct vers le serveur de base de données, ça risque d'être compliqué.

On peut déjà dans un premier temps voir comment gérer ça proprement "à la main" (i.e. en rédigeant des scripts de migration de schéma et d'import/modification pour les données existantes). Ca dépend après de la taille de ta base et de la quantité de donnée, mais ça ne sera pas pire que de perdre les données... Je vais supposer que la volumétrie n'est pas énorme, et que tu ne changes pas le schéma de ta base du tout au tout à chaque déploiement.

Il faudrait que tu maintiennes lorsque tu fais des modifications un document SQL avec ce qu'il faut de requêtes pour passer de la version N-1 de ta base à la version N. Comme ça, à chaque mise-à-jour, tu ne déploiera que la différence entre la base existante et ce que tu veux obtenir. La bonne chose, c'est que MySQL dispose d'une documentation relativement complète et assez claire. Je vais y faire référence par la suite.

Pour tout retrait, ajout de colonne ou en général modification de la structure d'une table existante, si tu ne veux pas le faire en cliquant partout sur phpMyAdmin (ce qui peut rester le plus simple si tu n'es pas très à l'aise avec SQL), il faut utiliser la commande ALTER TABLE.

Pour l'insertion de nouvelles données, utilise la commande INSERT comme tu le fais déjà. N'hésites pas à reprendre le fichier généré par l'export à partir de ton environnement de développement, en supprimant tous les tuples correspondants à des données qui existent déjà si c'est plus simple pour toi.

Pour la modification de données existantes, ça sera la commande UPDATE. Utile aussi quand tu ajoutes des colonnes mais que tu ne souhaites pas que les anciens enregistrements utilisent la valeur par défaut.

L'avantage d'un tel fichier, c'est qu'au moment du déploiement tu fais copier/coller de son contenu dans le champ de soumission de requête de phpMyAdmin, tu valides et c'est bon (à moins qu'il n'y ait des erreurs dans le script SQL). L'inconvénient, c'est que ça fonctionne bien quand tu n'as que des manipulations simples à faire, et que tu ne manipules que poignée de tables et d'enregistrements.

Ne pas oublier en tout cas avant toute mise à jour de faire une sauvegarde de l'état de la base de données, que tu peux utiliser pour remettre le site en état si la mise-à-jour se passe mal.

Enfin, plutôt que devoir aller soumettre ce genre de commandes à la main dans phpMyAdmin, ça pourrait aussi être du code PHP spécifique qui pilote la mise-à-jour, de sorte que celle-ci pourrait se faire en déployant les fichiers en environnement de production suivi d'une visite à http://monSite.fr/update.php. Dans ce genre de cas, il vaut mieux s'assurer que l'opération de mise-à-jour ne foute pas la base en l'air si on l'exécute une seconde fois (ce qui a très très peu de chance d'arriver, le script SQL aurait plutôt tendance à s'arrêter en erreur sur la première commande en général).

En effet, ma base de donnée est très légère (quelques tables de quelques lignes seulement) et n'est modifiée qu'en local par mes soins. Donc pas de soucis de perte de donnée.

Je ne pratique pas beaucoup MySQL mais j'ai déjà écrit quelques lignes de codes pour modifier le contenu d'une table donc je sais grosso modo comment ça fonctionne et je cherchais justement une solution plus simple vu que mon utilisation est pour le moment assez sommaire...

Bonsoir,

La solution la plus simple serait de pouvoir exporter/importer les tables comme je le fais actuellement, mais que les tables soient automatiquement complètement écrasées au niveau structure et données lors de l'importation.

Tu peux exporter ta base via phpMyAdmin avec l'option "Vider la table avant d'insérer". Ensuite à l'importation, le script virera les données pour mettre celle de la base exporter.

Bien sur, cela implique la perte des données modifiées dans la base cible...

Alors ça, ça me parle ! Je n'ai jamais pensé à vraiment fouiller dans les options d'export mais je ne trouve pas cette option... Ce qui se rapproche le plus serait la case à cocher DROP TABLE ?

Si c'est bien ça, est ce que ça supprime complètement la table (structure et contenu) avant de recréer la structure et réimporter le contenu ? (grosse journée = la flemme de faire un test ce soir...)

Parce que si c'est aussi simple que ça, ça va carrément me simplifier la vie sans me prendre la tête

[RFN]

Oui, c'est tout à fait cela. La différence de termes doit provenir de version différente de phpMyAdmin.

Chaque table contenue dans l'export sera rechargée après un Drop table, ce qui détruit bien la table précédente (structure et données). Le script d'importation procédera donc ensuite à un create table, suisvi d'insert into pour y charger les données.

[KoRnMuse]

Je viens de faire un test vite fait sur une table bidon, et c'est juste parfait.

Un grand merci pour cette petite astuce à côté de laquelle j'étais passé.