Mysqldump é um utilitário cliente que é usado para realizar backups lógicos do banco de dados MySQL. Esta ferramenta de migração popular é útil para vários casos de uso do MySQL, como:
- Backup e restauração de bancos de dados.
- Migrando dados de um servidor para outro.
- Migração de dados entre diferentes provedores de serviços MySQL gerenciados.
- Migrando dados entre diferentes versões do MySQL.
O Mysqldump funciona lendo os objetos do banco de dados de origem e gerando um conjunto de instruções SQL que são armazenadas em um arquivo de despejo. Ao reproduzir essas instruções no servidor de banco de dados de destino, os dados originais são reconstruídos. Como esse modelo usa a leitura de todo o banco de dados e, em seguida, a reconstrução, tanto o dump quanto a restauração são operações demoradas para um banco de dados grande. O processo pode até se tornar complicado se você encontrar erros durante o despejo ou a restauração, pois isso pode levar você a corrigir os problemas e executar novamente as operações. É por isso que é importante planejar bem antes de fazer o dump e restaurar a atividade.
Nesta série de blogs em duas partes, discutimos alguns dos aspectos comuns que você deve tratar antecipadamente para garantir uma atividade de despejo e restauração bem-sucedida. Na primeira parte, focamos nos pré-requisitos que você precisa ter cuidado ao importar os dados da tabela MySQL e na segunda parte, falaremos sobre como lidar com a importação de objetos e visualizações de programa armazenados.
1. Requisitos de espaço
Em primeiro lugar, é importante garantir que o volume do banco de dados de destino tenha espaço suficiente para armazenar os dados importados. Especificamente, você precisa ser cauteloso se os logs binários estiverem habilitados no banco de dados MySQL de destino, pois os logs binários gerados durante a importação dos dados podem ter um tamanho quase igual aos próprios dados. Os logs binários são necessários se você deseja restaurar seus dados em um servidor e deseja que eles sejam replicados. Nesses casos, é uma boa ideia planejar um tamanho de destino maior que o dobro do tamanho do banco de dados de origem.
Também é importante garantir que haja espaço suficiente disponível no volume onde você gera o arquivo de saída mysqldump. Sem essas precauções, você pode ver seu despejo ou restauração falhando devido a espaço insuficiente após a execução por um longo tempo, o que representa uma perda de tempo e esforço produtivos.
2. Sql_mode
as configurações de sql_mode para o servidor MySQL determinam a sintaxe da instrução SQL e as verificações de validação de dados que o servidor executa para as operações. É importante garantir que o sql_mode dos servidores MySQL de origem e destino são compatíveis entre si, ou você pode encontrar falhas ao restaurar o dump que você fez. Vamos demonstrar isso com um exemplo.
Digamos que você tenha uma tabela em sua fonte que tenha uma coluna de data com entradas como datas zero:
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 | +------+------------+
Suponha o estrito sql_mode (e NO_ZERO_DATE ) está desabilitado na origem, mas habilitado no destino - restaurar essas linhas resultará em falhas como:
ERROR 1292 (22007) at line 40: Incorrect date value: '0000-00-00' for column 'ts’' at row 2
Você normalmente verá esses problemas se estiver fazendo um dump compacto habilitando a opção compact como parte do seu mysqldump.
Se compact estiver desabilitado (que é por padrão), você não enfrentará esse problema, pois o mysqldump gera a seguinte instrução condicional como parte do dump:
/*!40101 SET @OLD_SQL_MODE=@@SQL_MODE,SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
Isso significa que durante a restauração sql_mode está definido como 'NO_AUTO_VALUE_ON_ZERO' antes de restaurar os dados da tabela para que a restauração ocorra bem.
Prática recomendada para mysqldump:Parte 1 - Pré-requisitos do MySQLClick To Tweet
3. Unique_checks e Foreign_key_checks
Por padrão (se você não usar a opção –compact), o mysqldump também define o seguinte:
/*!40014 SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0 */; /*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
Como explicado aqui, você pode acelerar a operação de restauração desativando temporariamente as verificações de exclusividade durante a sessão. Para tabelas grandes, isso economiza muita E/S de disco porque o InnoDB pode usar seu buffer de alteração para gravar registros de índice secundários em um lote.
Se você tiver FOREIGN KEY restrições em suas tabelas, você pode acelerar a operação de restauração de tabela desativando as verificações de chave estrangeira durante a sessão de restauração:Para tabelas grandes, isso pode economizar muita E/S de disco.
Desativando FOREIGN_KEY_CHECKS também ajudará a evitar erros devido a verificações de restrição de chave foregin durante a operação de restauração. Sempre que uma tabela com restrição de chave foregin é criada, o MySQL espera que a tabela pai que é referenciada pela chave foregin já exista. Isso é um problema, pois o utilitário mysqldump despeja as tabelas em ordem alfabética. Vamos dar um exemplo para demonstrar isso.
No banco de dados de origem, temos duas tabelas:
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`) )
A tabela ref_table tem uma restrição de chave estrangeira que faz referência à solution_table . Com base na ordem alfabética, o mysqldump primeiro despeja o conteúdo de ref_table . Quando isso for repetido no momento da restauração, ele falhará com o erro:
ERROR 1215 (HY000) at line 50: Cannot add foreign key constraint -
O que acontece durante a execução da instrução create table para ‘ref_table’ .
Em resumo, esteja ciente dos problemas que você pode encontrar se especificar --compact opção durante a execução do mysqldump.
4. Privilégios necessários para executar o mysqldump
O privilégio mínimo exigido pelo mysqldump para despejar um banco de dados é SELECT nesse banco de dados.
No entanto, se seu banco de dados tiver visualizações, você também precisará de permissões SHOW VIEW, pois o mysqldump sempre despeja visualizações junto com as tabelas do banco de dados. Suponha que você não tenha SHOW VIEW permissões, então o mysqldump falhará com:
mysqldump: Couldn't execute 'show create table `ivew`': SHOW VIEW command denied to user ‘dumpuser’@'172.31.18.79' for table 'iview' (1142)
Outro ponto de interesse é se seu dumpuser tem SELECT permissões somente em uma tabela específica do banco de dados, o mysqldump despejará dados apenas para essa tabela específica e ignorará automaticamente quaisquer outras tabelas ou visualizações.
Assim, certifique-se de que o usuário que executa o mysqldump tenha todos os privilégios apropriados antecipadamente para evitar surpresas ou falhas posteriormente.
|
5. Max_allowed_packet
O maior pacote de comunicação manipulado pelo mysql é determinado pela configuração max_allowed_packet . No contexto de importação, um pacote de comunicação é uma única instrução SQL enviada ao servidor MySQL durante a restauração OU uma única linha enviada ao cliente durante o dump.
O valor padrão de max_allowed_packet para mysqldump é de 24 MB. se o mysqldump receber um pacote maior que isso, você poderá encontrar o erro:
mysqldump: Error 2020: Got packet bigger than 'max_allowed_packet' bytes when dumping table `huge1` at row: 2.
Assegure-se de que o mysqldump use o mesmo valor ou maior de max_allowed_packet que está configurado na instância MySQL de origem.
A opção pode ser especificada com o sinalizador --max-allowed-packet=value ao invocar o mysqldump.
Ao restaurar o dump, certifique-se de que max_allowed_packet tamanho do seu servidor de destino é grande o suficiente para receber os pacotes do arquivo de despejo.
Caso contrário, durante a restauração do dump, você verá uma mensagem de erro:
ERROR 2006 (HY000) at line 70: MySQL server has gone away
Este erro pode ser um pouco enganador, pois você pode pensar que o servidor MySQL foi desligado ou travou. Mas, isso significa apenas que o servidor recebeu um pacote de tamanho maior do que o tamanho configurado de max_allowed_packet . Novamente, a melhor prática é garantir que o max_allowed_packet valor para seu servidor de destino é o mesmo que o valor no servidor de origem. Essa também é uma configuração importante que pode ser verificada e definida adequadamente antecipadamente, em vez de enfrentar os erros posteriormente.
Nesta primeira parte da série mysqldump, discutimos os pré-requisitos para uma operação de dump e restauração bem-sucedida para grandes bancos de dados MySQL para ajudá-lo a evitar várias tentativas e tempo improdutivo gasto.
Na próxima parte, discutiremos as melhores práticas para importar os programas e visualizações armazenados de seu banco de dados MySQL.
