Hola, amantes de Habra! Hoy decidí compartir mi versión de copia de seguridad de datos de MySql y hablar sobre cómo se puede usar para el control de versiones en Git. Y si está interesado en saber cómo puede monitorear el estado de la base de datos en todas las etapas de desarrollo, o simplemente hacer las copias de seguridad correctas de su base de datos del proyecto e implementarla en cualquier momento, ¡léala!
Que es esto
Este es un conjunto de scripts escritos en BASH, que les permite trabajar en casi cualquier máquina en la que funcione este shell, diseñado para facilitar la creación y despliegue de copias de seguridad. La idea original era que podía crear puntos de interrupción de la base de datos al escribir un proyecto por un equipo de desarrolladores y almacenarlo en un gita, sé que hay cosas más serias para este propósito, y esta solución no pretende estar en su lugar.
Para quien
Por ejemplo, prefiere desarrollar el sitio de inmediato en el alojamiento del cliente y controlar el progreso del desarrollo y los cambios en la base de datos. O tiene poco dinero (o el sapo estrangula) para gastarlo en buenos productos de control de versiones de bases de datos. También puede usar el proyecto como una copia de seguridad de datos para ciertas reglas, que pueden ser utilizadas por Crown. Y, por supuesto, es útil si usted es un desarrollador novato y está comenzando a aprender los conceptos básicos del desarrollo, y periódicamente tiene el número 500 y no sabe por qué. O está desarrollando un producto como un equipo y desea sincronizarlo automáticamente con la producción al presionar al maestro para evaluar al cliente.
Considere un ejemplo de desarrollo de sitio estándar en el lado del host (la mayoría de los casos):
- Hay un servidor en el que gira el proyecto y lo más probable es que sea una máquina local o un cliente que aloja el proyecto actual.
- Hay una computadora local para la que trabaja y, según la tradición, almacena archivos e instantáneas de los estados allí.
- Y Producción, aquí es donde se fusiona el producto final, pero también puede ser el primer elemento, solo otra carpeta.
¿Cómo trabajar con eso?
Para cumplir con el control de versiones de la base de datos usando git, obviamente necesita obtener sus volcados en algunas etapas, dónde almacenarlos en algún lugar y, al cambiar de sucursal, tenga en cuenta este punto. Para esto, utilicé git hooks, que son los archivos de los scripts correspondientes (deben instalarse en la computadora local donde se usa git). Dependiendo de la configuración del archivo de configuración, el proceso de trabajo puede verse de la siguiente manera:
Creamos una rama (la copia de seguridad se realizó automáticamente) y cambiamos, trabajamos, agregamos archivos, creamos una confirmación (la copia de seguridad se realizó automáticamente) ...
cambiado a verificación maestra, la base de datos cambió al estado anterior ...
volvió al desarrollo, fusionó ramas, comenzó. Es decir las copias de seguridad se crean automáticamente durante las confirmaciones,
forzado antes de finalizar la compra, el comportamiento se configura en la configuración. Puede llamar manualmente a exportar o importar la base de datos en el servidor, desde su computadora local, ejecutando el script apropiado.
Para cada script, puede obtener ayuda de la manera clásica usando los argumentos -h o --help.
No recomiendo hacer una copia de seguridad de toda la base de datos, a git no le gustan los archivos grandes, y en la mayoría de los casos esto no es necesario. Por lo tanto, puede configurarlo fácilmente usando config.ini Dado que la configuración se usa tanto en el lado del servidor (en el que se levanta mySql) como en el lado del cliente (computadora del desarrollador), el mismo archivo es responsable de la configuración. Y, por supuesto, puede ser la misma computadora si está desarrollando localmente.
Qué se puede configurar para crear un volcado
- Configuración de conexión de base de datos y rutas de almacenamiento de volcado
- Indicación de un proveedor que podrá no solo obtener datos de conexión de la base de datos, sino
y borre correctamente el caché en el servidor al cambiar de sucursal. - Exportar toda la base de datos
- Lista de tablas que se excluirán de la exportación.
- O exportar tablas específicas
- Guardar una estructura sin insertar datos en ciertas tablas
- Especificar campos para tablas cuyos valores no deben exportarse, y deben
ser reemplazado con valores predeterminados. - Separe los conjuntos de reglas en una configuración, lo que le permitirá hacer diferentes copias de seguridad por CRON
Para facilitar el proceso de creación de vertederos. Usé proveedores de archivos. Y configurado (hasta ahora el único) para la revolución CMS MODX. En base a esto, puede escribir el mismo proveedor para cualquier CMS.
Breves pasos para comenzar
, .git, , git [git clone ](https://github.com/Setest/.git-db-watcher) chmod +x install.sh; ./install.sh , ./install.sh -nh
Ahora necesita hacer cambios en config.ini . Por ejemplo, así:
; [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 todo está configurado correctamente, puede ejecutar ./export.sh y debería
Aparecerá un volcado de la base de datos en la computadora local y en el servidor.
Otras preguntas
Necesito guardar el resultado en el servidor en otro lugar:
./db_export.sh --output 1>./xxx.sql
Quiero exportar en el servidor usando los datos en mi sección del archivo de configuración:
./db_export.sh -=only_users --output 1>./users.sql
Quiero importar un archivo de base de datos, pero no quiero hacerlo a través de interceptores 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
¿Cómo importar mientras se está en el servidor?
./db_import.sh < db_backup/db.sql
En diferentes proyectos, uso CMS xxx y estoy cansado de ingresar datos cada vez
para la gestión de bases de datos, ¿cómo puedo simplificar el proceso?
Para hacer esto, debe escribir su archivo de proveedor por analogía con los existentes.
Creé un trabajo y configuración CRON usando el proveedor php, pero
no se ejecuta o el caché del sitio CMS no se borra, ¿cuál podría ser el problema?
Dependiendo de la configuración del servidor y del trabajo en sí, los trabajos CRON pueden ejecutarse en un entorno completamente diferente, en el que la ruta al preprocesador php puede diferir y, como resultado, ejecutar una versión completamente diferente de php que no es compatible con la que está ejecutando su CMS.
Epílogo
Nunca escribí scripts en BASH y, por lo tanto, probablemente nagovokodil , Estoy seguro de que hay personas competentes que, si están interesadas, podrán agregar sus ediciones. Desarrollaré el proyecto como el interés entrante y la identificación de errores en el trabajo.
Y no apestas de inmediato que nada funciona, tal vez no puedas descubrir cómo configurarlo e instalarlo correctamente (especialmente si estás trabajando en Windows, aunque BASH es un entorno Linux).
Las instrucciones de instalación y uso están en README. Traté de escribir inmediatamente en inglés, pero también debido a mi nivel de aficionado, tal vez no todo esté claro, en el futuro escribiré en ruso. Si desea realizar cambios en la traducción o el código, ¡bifurque para la salud! Y si hay buenos consejos, compártalos.
PD: si lees hasta el fondo, entonces se volvió interesante y ansioso por probar :-)
¡Entonces ve más audaz a esta referencia!