Na segunda e última parte de nossas práticas recomendadas do mysqldump, falaremos sobre como lidar com a migração e importação de objetos de programa armazenados e visualizações de seu banco de dados MySQL. Para ler mais sobre os pré-requisitos para uma operação de despejo e restauração bem-sucedida para grandes bancos de dados MySQL, confira a primeira parte desta série de blogs em duas partes.
Importando seus procedimentos armazenados, funções e gatilhos
Por padrão, mysqldump importa views e triggers. Porém não importa procedimentos, funções e eventos. Para importar procedimentos e funções, o --routines opção deve ser especificada, e para importar eventos, o --events opção deve ser especificada.
1. Importando acionadores
O Mysqldump tentará despejar todos os triggers em seu banco de dados por padrão. Para poder despejar os triggers de uma tabela , você deve ter o TRIGGER privilégio para a mesa. Se o usuário dump não tiver este privilégio, os triggers serão ignorados e o mysqldump não lançará nenhum erro. Portanto, não se surpreenda se você não vir nenhum gatilho importado para seu banco de dados de destino.
2. Importando eventos
Para importar eventos, você precisa especificar --events opção ao chamar o utilitário mysqldump. Esta opção requer o EVENT privilégios para esses bancos de dados. Novamente, mysqldump irá pular eventos silenciosamente se o usuário dump não tiver esses privilégios, mesmo se você tiver especificado a opção –event ao invocar mysqldump.
3. Importando funções e procedimento armazenado
Para importar rotinas, você precisa especificar --routines opção ao chamar o utilitário mysqldump. Esta opção requer a global select privilégios. Mesmo neste caso, mysqldump irá pular funções e procedimentos silenciosamente se o usuário dump não tiver esses privilégios, mesmo se você tiver especificado --routines opção ao chamar mysqldump.
3.1 Importando funções não determinísticas
Um programa armazenado que modifica dados é chamado não determinístico se não produzir resultados repetíveis. Exemplo de função rand(). É especialmente desafiador usar essas funções em configurações replicadas, pois elas podem resultar em dados diferentes na origem e na réplica. Para controlar tais possibilidades, o MySQL impõe certas restrições na criação de funções se os logs binários estiverem habilitados.
Por padrão, para uma CREATE FUNCTION declaração a ser aceita, pelo menos um de DETERMINISTIC , NO SQL , ou READS SQL DATA deve ser especificado explicitamente. Caso contrário, ocorre um erro:
ERRO 1418 (HY000) na linha 181:Esta função não tem DETERMINISTIC, NO SQL ou READS SQL DATA em sua declaração e o log binário está habilitado (você *pode* querer usar o log_bin_trust_funable menos seguro)
Portanto, se sua função não for declarada como determinística na origem e o log binário estiver ativado em seu destino, você verá o erro acima durante a restauração do dump. Por isso, é importante entender antecipadamente a natureza determinística de suas funções. Se você tem certeza de que suas funções são determinísticas, você precisa ativar os log_bin_trust_function_creators configuração em seu destino antes da operação de restauração. Quando habilitado, o MySQL permite a criação de tais funções mesmo quando o log binário está habilitado.
Prática recomendada para mysqldump:Parte 2 - Guia de migraçãoClick To Tweet
4. SEGURANÇA SQL característica das rotinas e visualizações armazenadas.
O MySQL permite um SQL SECURITY contexto a ser especificado ao criar os programas ou visualizações da loja. A SQL SECURITY característica pode ser especificada como DEFINER ou INVOKER . Se o SQL_SECURITY contexto é DEFINER , a rotina executa usando os privilégios da conta nomeada na rotina DEFINER cláusula. Se o contexto for INVOKER , a rotina é executada usando os privilégios do usuário que a invoca. O valor padrão é DEFINER .
Se você estiver restaurando rotinas ou exibições armazenadas, precisará garantir que a conta de usuário definidora exista no banco de dados de destino com as concessões apropriadas. Caso contrário, você encontrará falhas durante a restauração.
Vamos demonstrar isso com um exemplo relacionado a visualizações.
Vamos supor que você tenha as definições de Views V1 e V2 conforme abaixo:
CREATE definer=admin@'%' VIEW mydb.V1 AS SELECT * FROM solution_table;CREATE definer=admin@'%' VIEW mydb.V2 AS SELECT * FROM V1 onde num1=10;
Observe que as visualizações são despejadas por padrão pelo mysqldump e se você não tiver o usuário ‘admin’ em seu destino, você encontrará o erro abaixo durante a operação de restauração:
Falha no comando com erro - ERRO 1449 (HY000) na linha 206 do arquivo:'/mysql_data/mysqldump/sqldump_1582457155758.sql':O usuário especificado como definidor ('admin'@'%') não existe. Observe que não é apenas suficiente garantir que o usuário existe, mas o usuário precisa ter privilégios apropriados para executar as visualizações. Por exemplo, se o usuário admin@'%' existe no destino, mas não tem SELECT privilégios no banco de dados mydb, você verá uma mensagem de erro:
'/mysql_data/mysqldump/sqldump_1582456858033.sql':View 'mydb.V2' referencia tabela(s) ou coluna(s) ou função(ões) inválida(s) ou definidor/invocador de view não tem direitos para usá-los.
pré>
|
Resumo
Nesta série de blogs em duas partes, abordamos pré-requisitos importantes que você precisa lidar para garantir a migração bem-sucedida de seus dados e programas armazenados. A hospedagem MySQL do ScaleGrid lida com essas diretrizes para fornecer uma experiência tranquila ao importar seus dados para a plataforma ScaleGrid. Por favor, compartilhe conosco sua experiência e práticas recomendadas que você adota para migrações de dados MySQL!
