Bonjour, amoureux Habra! Aujourd'hui, j'ai décidé de partager ma version de sauvegarde de données à partir de MySql et de parler de la façon dont elle peut être utilisée pour le contrôle de version dans Git. Et si vous souhaitez savoir comment surveiller l'état de la base de données à toutes les étapes de développement, ou simplement effectuer les sauvegardes correctes de votre base de données de projet et la déployer à tout moment, alors lisez-la!
Qu'est ce que c'est
Il s'agit d'un ensemble de scripts écrits en BASH, qui leur permet de travailler sur presque toutes les machines sur lesquelles ce shell fonctionne, conçu pour faciliter la création et le déploiement de sauvegardes. L'idée originale était que vous pouviez créer des points d'arrêt de base de données lors de l'écriture d'un projet par une équipe de développeurs, et le stocker dans une gita, je sais qu'il y a des choses plus sérieuses à cet effet, et cette solution ne prétend pas être à leur place.
Pour qui?
Par exemple, vous préférez développer le site immédiatement sur l'hébergement du client et suivre l'avancement du développement et l'évolution de la base de données. Soit vous avez peu d'argent (ou les étranglements du crapaud) pour le dépenser en bons produits de contrôle de version de base de données. Vous pouvez également utiliser le projet comme sauvegarde de données pour certaines règles, qui peuvent être utilisées par Crown. Et bien sûr, cela vous sera utile si vous êtes un développeur débutant et que vous commencez tout juste à apprendre les bases du développement, que vous avez régulièrement le 500e et que vous ne savez pas pourquoi. Ou vous développez un produit en équipe et vous souhaitez le synchroniser automatiquement avec la production lorsque vous faites appel au maître pour évaluer le client.
Prenons un exemple de développement de site standard côté hôte (la plupart des cas):
- Il existe un serveur sur lequel le projet tourne et il s'agit très probablement d'une machine locale ou d'un client hébergeant le projet en cours.
- Il y a un ordinateur local pour lequel vous travaillez et, selon la tradition, vous y stockez des fichiers et des instantanés d'états.
- Et la production, c'est là que le produit final fusionne - mais il peut aussi s'agir du 1er élément, juste un autre dossier.
Comment travailler avec?
Afin de respecter le contrôle de version de la base de données à l'aide de git, vous devez évidemment obtenir ses vidages à certaines étapes, où les stocker quelque part et lorsque vous changez de branche, considérez ce point. Pour cela, j'ai utilisé des hooks git, qui sont les fichiers des scripts correspondants (ils doivent être installés sur l'ordinateur local sur lequel git est utilisé). Selon les paramètres du fichier de configuration, le processus de travail peut se présenter comme suit:
Nous créons une branche (la sauvegarde a eu lieu automatiquement) et changeons, travaillons, ajoutons des fichiers, créons un commit (la sauvegarde a eu lieu automatiquement) ...
passé à la vérification principale, la base de données est passée à l'état précédent ...
retourné au développement, fusion des succursales, a commencé. C'est-à-dire les sauvegardes sont automatiquement créées lors des validations,
soit forcé avant le paiement, le comportement est configuré dans la configuration. Vous pouvez appeler manuellement exporter ou importer la base de données sur le serveur, à partir de votre ordinateur local, en exécutant le script approprié.
Pour chaque script, vous pouvez obtenir de l'aide de manière classique en utilisant les arguments -h ou --help.
Je ne recommande pas de sauvegarder l'intégralité de la base de données, git n'aime pas les gros fichiers, et dans la plupart des cas, ce n'est pas nécessaire. Par conséquent, vous pouvez facilement configurer en utilisant config.ini Comme les paramètres sont utilisés à la fois côté serveur (sur lequel mySql est élevé) et côté client (ordinateur du développeur), le même fichier est responsable de la configuration. Et bien sûr, il peut s'agir du même ordinateur si vous développez localement.
Que peut-on configurer pour créer un vidage
- Paramètres de connexion à la base de données et chemins de stockage de vidage
- Indication d'un fournisseur qui pourra non seulement obtenir des données de connexion à la base de données, mais
et vider correctement le cache sur le serveur lors du changement de branche. - Exporter la base de données entière
- Liste des tableaux à exclure de l'exportation
- Ou exporter des tables spécifiques
- Enregistrement d'une structure sans insertion de données dans certaines tables
- Spécification de champs pour les tables dont les valeurs ne doivent pas être exportées et doivent
être remplacé par des valeurs par défaut. - Jeux de règles séparés dans une seule configuration, ce qui vous permettra de faire différentes sauvegardes par CRON
Afin de faciliter le processus de création de vidages. J'ai utilisé des fournisseurs de fichiers. Et mis en place (jusqu'à présent le seul) pour la révolution CMS MODX. Sur cette base, vous pouvez écrire le même fournisseur pour n'importe quel CMS.
Brèves étapes pour commencer
, .git, , git [git clone ](https://github.com/Setest/.git-db-watcher) chmod +x install.sh; ./install.sh , ./install.sh -nh
Vous devez maintenant apporter des modifications à config.ini . Par exemple, comme ceci:
; [hooks] ; H_CHECK_DB_HASH_BEFORE_CHECKOUT=1 ; checkout ; ; git checkout -b new_branch_name H_CHECKOUT_FORCE=0 ; H_CHECKOUT_EVERCOM=1 ; H_CHECKOUT_CLEARCACHE=1 [common] ; EXPORT_FILE="db.sql" ; ; ./export.sh [develop] ; db_export.sh CLI_DB_EXPORT="ssh host '/path/to/project/on/server/.git-db-watcher/db_export.sh'" CLI_DB_IMPORT="ssh host '/path/to/project/on/server/.git-db-watcher/db_import.sh'" ; [server] PHP_PATH="/usr/local/bin/php" CONFIG_INC_PATH="/path/to/project/on/server/core/config/config.inc.php" PROVIDER=modx DB_TABLES_INCLUDE=site_content DB_TABLES_AUTOPREFIX=1 [server_full_site] PHP_PATH="/usr/local/bin/php" CONFIG_INC_PATH="/path/to/project/on/server/core/config/config.inc.php" ; '' - DB_CONFIG_ ; providers PROVIDER=modx ; DB_CONFIG_HOST= DB_CONFIG_TYPE= DB_CONFIG_USER= DB_CONFIG_PASSWORD= DB_CONFIG_CONNECTION_CHARSET= DB_CONFIG_DBASE= DB_CONFIG_TABLE_PREFIX= DB_CONFIG_DATABASE_DSN= ; ( ) ; ; DB_TABLES_INCLUDE=manager_log register_messages user_attributes ; DB_TABLES_INCLUDE=site_content ; ; DB_TABLES_EXCLUDE=session register_messages mse2_words ec_messages ; , , DB_TABLES_AUTOPREFIX=1 ; INSERT DB_TABLES_REMOVE_INSERT="manager_log session register_messages" ; DB_TABLES_REMOVE_INSERT="manager_log" ; ; DB_TABLES_DEFAULT=user_attributes users DB_TABLES_DEFAULT=user_attributes ; , ; , ; DB_TABLES_DEFAULT_user_attributes=sessionid logincount lastlogin thislogin ; DB_TABLES_DEFAULT_users=session_stale ; , [only_users] DB_TABLES_INCLUDE=user user_attributes EXPORT_FILE="users.sql" DB_TABLES_DEFAULT=user_attributes user DB_TABLES_DEFAULT_user_attributes=sessionid logincount lastlogin thislogin DB_TABLES_DEFAULT_users=session_stale
Si tout est correctement configuré, vous pouvez exécuter ./export.sh et vous devez
Un vidage de la base de données apparaîtra sur l'ordinateur local et sur le serveur.
D'autres questions
J'ai besoin de sauvegarder le résultat sur le serveur à un autre endroit:
./db_export.sh --output 1>./xxx.sql
Je souhaite exporter sur le serveur en utilisant les données de ma section du fichier de configuration:
./db_export.sh -=only_users --output 1>./users.sql
Je veux importer un fichier de base de données, mais je ne veux pas le faire via des intercepteurs GIT?
./import.sh ./import.sh EXPORT_FILE=site_name.sql ./import.sh DB_BACKUP_FILE=/.../../site_name.sql ./import.sh --config=site DB_BACKUP_FILE=./site_name.sql
A comment importer tout en étant sur le serveur?
./db_import.sh < db_backup/db.sql
Dans différents projets, j'utilise CMS xxx et je suis fatigué de saisir des données à chaque fois
pour la gestion des bases de données, comment puis-je simplifier le processus?
Pour ce faire, vous devez écrire votre fichier fournisseur par analogie avec les fichiers existants.
J'ai créé un travail et une configuration CRON à l'aide du fournisseur php, mais il
ne fonctionne pas ou le cache du site CMS n'est pas effacé, quel pourrait être le problème?
Selon les paramètres du serveur et le travail lui-même, les travaux CRON peuvent s'exécuter dans un environnement complètement différent, dans lequel le chemin vers le préprocesseur php peut différer et, par conséquent, exécuter une version complètement différente de php qui n'est pas compatible avec celle sur laquelle votre CMS s'exécute.
Postface
Je n'ai jamais écrit de scripts sur BASH et donc probablement nagovokodil , Je suis sûr qu'il y a des gars compétents qui, s'ils sont intéressés, pourront ajouter leurs modifications. Je développerai le projet comme l'intérêt entrant et l'identification des erreurs dans le travail.
Et ne pensez pas immédiatement que rien ne fonctionne, peut-être ne pourriez-vous pas comprendre comment configurer et installer correctement (surtout si vous travaillez sous Windows, mais BASH est un environnement Linux).
Les instructions d'installation et d'utilisation se trouvent dans le fichier README. J'ai essayé d'écrire immédiatement en anglais, mais aussi à cause de mon niveau amateur, peut-être que tout ne sera pas clair, à l'avenir j'écrirai en russe. Si vous souhaitez apporter des modifications à la traduction ou au code, bifurquez pour la santé! Et s'il y a de bons conseils, partagez-les.
PS: si vous lisez en bas, alors c'est devenu intéressant et impatient d'essayer :-)
Alors allez plus audacieux à cette référence!