Mysqldump es una utilidad de cliente que se utiliza para realizar copias de seguridad lógicas de la base de datos MySQL. Esta popular herramienta de migración es útil para varios casos de uso de MySQL como:
- Copia de seguridad y restauración de bases de datos.
- Migración de datos de un servidor a otro.
- Migración de datos a través de diferentes proveedores de servicios MySQL administrados.
- Migración de datos entre diferentes versiones de MySQL.
Mysqldump funciona leyendo los objetos de la base de datos de origen y generando un conjunto de sentencias SQL que se almacenan en un archivo de volcado. Al reproducir estas declaraciones en el servidor de la base de datos de destino, se reconstruyen los datos originales. Dado que este modelo utiliza la lectura de toda la base de datos y luego esencialmente la reconstrucción, tanto el volcado como la restauración son operaciones que requieren mucho tiempo para una base de datos grande. El proceso puede incluso volverse engorroso si encuentra errores durante el volcado o la restauración, ya que puede llevarlo a solucionar los problemas y volver a ejecutar las operaciones. Por eso es importante planificar bien antes de iniciar la actividad de volcado y restauración.
En esta serie de blogs de dos partes, discutimos algunos de los aspectos comunes que debe manejar por adelantado para garantizar una actividad exitosa de volcado y restauración. En la primera parte, nos enfocamos en los requisitos previos que debe tener en cuenta al importar los datos de la tabla MySQL y en la segunda parte, hablaremos sobre cómo manejar la importación de vistas y objetos de programas almacenados.
1. Requisitos de espacio
En primer lugar, es importante asegurarse de que el volumen de la base de datos de destino tenga espacio suficiente para almacenar los datos importados. Específicamente, debe tener cuidado si los registros binarios están habilitados en su base de datos MySQL de destino, ya que los registros binarios generados al importar los datos pueden tener casi el mismo tamaño que los propios datos. Los registros binarios son necesarios si desea restaurar sus datos en un servidor y desea que se replique. En tales casos, es una buena idea planificar un tamaño de destino superior al doble del tamaño de la base de datos de origen.
También es importante asegurarse de que haya suficiente espacio disponible en el volumen donde genera el archivo de salida mysqldump. Sin estas precauciones, es posible que su volcado o restauración falle debido a espacio insuficiente después de ejecutarse durante mucho tiempo, lo que es una pérdida de su tiempo y esfuerzo productivos.
2. Modo_sql
La configuración de sql_mode para el servidor MySQL determina la sintaxis de las sentencias SQL y las comprobaciones de validación de datos que realiza el servidor para las operaciones. Es importante asegurarse de que sql_mode de los servidores MySQL de origen y de destino son compatibles entre sí, o puede encontrar fallas al restaurar el volcado que ha tomado. Demostremos esto con un ejemplo.
Supongamos que tiene una tabla en su fuente que tiene una columna de fecha con entradas como fechas cero:
mysql> show create table sched; --------------------------------------------------------+ | Table | Create Table | --------------------------------------------------------+ | sched | CREATE TABLE `sched` ( `id` int(11) DEFAULT NULL, `ts` date DEFAULT NULL ) ENGINE=InnoDB DEFAULT CHARSET=latin1 | +-------+--------------------------------------------------------------------------------------------------------------------- mysql> select * from sched; +------+------------+ | id | ts | +------+------------+ | 1 | 2020-01-12 | | 2 | 0000-00-00 | +------+------------+
Supongamos que el estricto sql_mode (y NO_ZERO_DATE ) está deshabilitado en el origen, pero habilitado en el destino; la restauración de dichas filas provocará un error como:
ERROR 1292 (22007) at line 40: Incorrect date value: '0000-00-00' for column 'ts’' at row 2
Por lo general, verá este tipo de problemas si está realizando un volcado compacto al habilitar la opción compacta como parte de su mysqldump.
Si la compactación está deshabilitada (lo cual es predeterminado), entonces no enfrentará este problema ya que mysqldump genera la siguiente declaración condicional como parte del volcado:
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE,SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
Esto significa que durante la restauración sql_mode se establece en 'NO_AUTO_VALUE_ON_ZERO' antes de restaurar los datos de la tabla para que la restauración funcione bien.
3. Comprobaciones_únicas y comprobaciones_clave_externas
Por defecto (si no usa la opción –compact), mysqldump también establece lo siguiente:
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */; /*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
Como se explica aquí, puede acelerar la operación de restauración desactivando temporalmente las comprobaciones de unicidad durante la sesión. Para tablas grandes, esto ahorra una gran cantidad de E/S de disco porque InnoDB puede usar su búfer de cambios para escribir registros de índice secundarios en un lote.
Si tiene FOREIGN KEY restricciones en sus tablas, puede acelerar la operación de restauración de tablas desactivando las comprobaciones de clave externa durante la sesión de restauración:para tablas grandes, esto puede ahorrar una gran cantidad de E/S de disco.
Deshabilitar FOREIGN_KEY_CHECKS también ayudará a evitar errores debido a comprobaciones de restricciones de claves foráneas durante la operación de restauración. Cada vez que se crea una tabla con una restricción de clave foránea, MySQL espera que la tabla principal a la que hace referencia la clave foránea ya exista. Esto es un problema ya que la utilidad mysqldump vuelca las tablas en orden alfabético. Tomemos un ejemplo para demostrar esto.
En la base de datos de origen, tenemos dos tablas:
CREATE TABLE `solution_table` ( `num1` int(11) NOT NULL, `num2` int(11) DEFAULT NULL, PRIMARY KEY (`num1`)); CREATE TABLE `ref_table` ( `key` int(11) DEFAULT NULL, `ref_num` int(11) DEFAULT NULL, KEY `ref_num` (`ref_num`), CONSTRAINT `ref_num_ibfk_1` FOREIGN KEY (`ref_num`) REFERENCES `solution_table` (`num1`) )
La tabla ref_table tiene una restricción de clave externa que hace referencia a solution_table . Según el orden alfabético, mysqldump primero descarga el contenido de ref_table . Cuando esto se reproduce en el momento de la restauración, fallará con el error:
ERROR 1215 (HY000) at line 50: Cannot add foreign key constraint -
Lo que sucede al ejecutar la declaración de creación de tabla para ‘ref_table’ .
En resumen, tenga en cuenta los problemas que puede encontrar si especifica --compact opción mientras se ejecuta mysqldump.
4. Privilegios necesarios para ejecutar mysqldump
El privilegio mínimo requerido por mysqldump para volcar una base de datos es SELECT en esa base de datos.
Sin embargo, si su base de datos tiene vistas, también necesitará permisos SHOW VIEW, ya que mysqldump siempre volca las vistas junto con las tablas de la base de datos. Suponga que no tiene SHOW VIEW permisos, mysqldump fallará con:
mysqldump: Couldn't execute 'show create table `ivew`': SHOW VIEW command denied to user ‘dumpuser’@'172.31.18.79' for table 'iview' (1142)
Otro punto de interés es si su usuario de volcado tiene SELECT permisos solo en una tabla en particular de la base de datos, mysqldump volcará datos solo para esa tabla en particular e ignorará automáticamente cualquier otra tabla o vista.
Por lo tanto, asegúrese de que el usuario que ejecuta mysqldump tenga todos los privilegios apropiados por adelantado para evitar sorpresas o fallas en el futuro.
|
5. Max_allowed_packet
El paquete de comunicación más grande manejado por mysql está determinado por la configuración max_allowed_packet . En el contexto de la importación, un paquete de comunicación es una sola instrucción SQL enviada al servidor MySQL durante la restauración O una sola fila que se envía al cliente durante el volcado.
El valor predeterminado de max_allowed_packet para mysqldump es de 24 MB. si mysqldump recibe un paquete más grande que este, entonces puede encontrarse con el error:
mysqldump: Error 2020: Got packet bigger than 'max_allowed_packet' bytes when dumping table `huge1` at row: 2.
Así que asegúrese de que mysqldump use el mismo o mayor valor de max_allowed_packet que está configurado en la instancia de MySQL de origen.
La opción se puede especificar con el indicador --max-allowed-packet=value al invocar mysqldump.
Al restaurar el volcado, asegúrese de que max_allowed_packet el tamaño de su servidor de destino es lo suficientemente grande para recibir los paquetes del archivo de volcado.
De lo contrario, durante la restauración del volcado, verá un mensaje de error:
ERROR 2006 (HY000) at line 70: MySQL server has gone away
Este error puede ser un poco engañoso, ya que puede pensar que el servidor MySQL se ha apagado o bloqueado. Pero, solo significa que el servidor ha recibido un paquete de mayor tamaño que su tamaño configurado de max_allowed_packet . Nuevamente, la mejor práctica es asegurarse de que el max_allowed_packet el valor de su servidor de destino es el mismo que el valor del servidor de origen. Esta también es una configuración importante que se puede verificar y configurar de manera adecuada por adelantado, en lugar de enfrentar los errores más adelante.
En esta primera parte de la serie mysqldump, discutimos los requisitos previos para una operación exitosa de volcado y restauración para grandes bases de datos MySQL para ayudarlo a evitar múltiples intentos y tiempo improductivo.
En la siguiente parte, discutiremos las mejores prácticas para importar los programas almacenados y las vistas desde su base de datos MySQL.
