En la segunda y última parte de nuestras mejores prácticas de mysqldump, hablaremos sobre cómo manejar la migración y la importación de vistas y objetos de programas almacenados desde su base de datos MySQL. Para obtener más información sobre los requisitos previos para una operación exitosa de volcado y restauración para grandes bases de datos MySQL, consulte la primera parte de esta serie de blogs de dos partes.
Importación de sus procedimientos almacenados, funciones y disparadores
Por defecto, mysqldump importa vistas y disparadores. Sin embargo, no importa procedimientos, funciones y eventos. Para importar procedimientos y funciones, las --routines se debe especificar la opción, y para importar eventos, el --events se debe especificar la opción.
1. Importación de activadores
Mysqldump intentará volcar todos los disparadores en su base de datos por defecto. Para poder volcar los triggers de una tabla , debe tener el TRIGGER privilegio para la mesa. Si el usuario de volcado no tiene este privilegio, los activadores se omitirán y mysqldump no arrojará ningún error. Así que no se sorprenda si no ve ningún disparador importado a su base de datos de destino.
2. Importación de eventos
Para importar eventos, debe especificar --events opción mientras se invoca la utilidad mysqldump. Esta opción requiere el EVENT privilegios para esas bases de datos. Una vez más, mysqldump omitirá eventos de forma silenciosa si el usuario de volcado no tiene estos privilegios, incluso si ha especificado la opción de evento al invocar mysqldump.
3. Importación de funciones y procedimiento almacenado
Para importar rutinas, debe especificar --routines opción mientras se invoca la utilidad mysqldump. Esta opción requiere la global select privilegios Incluso en este caso, mysqldump omitirá silenciosamente funciones y procedimientos si el usuario de volcado no tiene estos privilegios, incluso si ha especificado --routines opción al invocar mysqldump.
3.1 Importando funciones no deterministas
Un programa almacenado que modifica datos se llama no determinista si no produce resultados repetibles. Ejemplo de función rand(). Es especialmente desafiante usar tales funciones en configuraciones replicadas, ya que pueden generar datos diferentes en la fuente y la réplica. Para controlar tales posibilidades, MySQL impone ciertas restricciones en la creación de funciones si los registros binarios están habilitados.
Por defecto, para una CREATE FUNCTION declaración para ser aceptada, al menos una de DETERMINISTIC , NO SQL , o READS SQL DATA debe especificarse explícitamente. De lo contrario, se produce un error:
ERROR 1418 (HY000) at line 181: This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration and binary logging is enabled (you *might* want to use the less safe log_bin_trust_funable)
Entonces, si su función no se declara como determinista en el origen y el registro binario está habilitado en su destino, verá el error anterior durante la restauración del volcado. Por lo tanto, es importante comprender la naturaleza determinista de sus funciones por adelantado. Si está seguro de que sus funciones son deterministas, debe activar log_bin_trust_function_creators configuración en su destino antes de la operación de restauración. Cuando está habilitado, MySQL permite la creación de tales funciones incluso cuando el registro binario está habilitado.
4. SEGURIDAD SQL característica de las rutinas y vistas almacenadas.
MySQL permite una SQL SECURITY contexto que se especificará al crear los programas o vistas de la tienda. La SQL SECURITY la característica se puede especificar como DEFINER o INVOKER . Si SQL_SECURITY el contexto es DEFINER , la rutina se ejecuta usando los privilegios de la cuenta nombrada en la rutina DEFINER cláusula. Si el contexto es INVOKER , la rutina se ejecuta utilizando los privilegios del usuario que la invoca. El valor predeterminado es DEFINER .
Si está restaurando rutinas o vistas almacenadas, debe asegurarse de que la cuenta de usuario del definidor exista en su base de datos de destino con las concesiones adecuadas. De lo contrario, encontrará fallas durante la restauración.
Vamos a demostrar esto con un ejemplo relacionado con las vistas.
Supongamos que tiene Views V1 y V2 definidas a continuación:
CREATE definer=admin@'%' VIEW mydb.V1 AS SELECT * FROM solution_table; CREATE definer=admin@'%' VIEW mydb.V2 AS SELECT * FROM V1 where num1=10;
Tenga en cuenta que mysqldump descarga las vistas de forma predeterminada y, si no tiene el usuario 'admin' en su destino, encontrará el siguiente error durante la operación de restauración:
Command failed with error - ERROR 1449 (HY000) at line 206 in file: '/mysql_data/mysqldump/sqldump_1582457155758.sql': The user specified as a definer ('admin'@'%') does not exist. Tenga en cuenta que no solo es suficiente para garantizar que el usuario existe, sino que el usuario debe tener los privilegios adecuados para ejecutar las vistas. Por ejemplo, si el usuario admin@'%' existe en el destino, pero no tiene SELECT privilegios en la base de datos mydb, verá un mensaje de error:
'/mysql_data/mysqldump/sqldump_1582456858033.sql':View 'mydb.V2' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them.
|
Resumen
En esta serie de blogs de dos partes, cubrimos los requisitos previos importantes que debe manejar para garantizar una migración exitosa de sus datos y programas almacenados. El alojamiento ScaleGrid MySQL maneja estas pautas para brindar una experiencia fluida al importar sus datos a la plataforma ScaleGrid. ¡Comparta con nosotros su experiencia y las mejores prácticas que adopta para las migraciones de datos de MySQL!
