Práticas recomendadas para migrar para o Cloud SQL para MySQL

Há várias maneiras de migrar para o MySQL no Cloud SQL. A estratégia de migração de uma determinada origem depende de vários fatores, incluindo o tamanho do banco de dados, as expectativas de inatividade e a experiência dos engenheiros que realizam a migração. Vamos analisar algumas das estratégias de migração mais comuns.

Se você estiver migrando um banco de dados pequeno com apenas alguns gigabytes ou que contém dados estáticos, a abordagem mais fácil é fazer um despejo do banco de dados usando o utilitário mysqldump. Faça upload do arquivo dump no Cloud Storage e importe-o para uma instância do Cloud SQL seguindo as instruções no artigo sobre exportação e importação usando arquivos dump SQL.

Como os arquivos dump contêm instruções SQL lógicas, uma vantagem dessa abordagem é que é possível editar os arquivos dump antes de carregá-los no Cloud Storage. No entanto, devido a determinadas restrições do Cloud SQL, evite incluir qualquer item no arquivo dump que possa interromper uma importação, conforme listado nas práticas recomendadas para importar e exportar dados.

Ao migrar muitas instâncias do MySQL ou para migrações maiores, a melhor opção é usar o Database Migration Service (DMS) Esse serviço oferece uma variedade de caminhos de migração, incluindo caminhos para migrações homogêneas e heterogêneas para o MySQL, além de suporte para SQL Server e PostgreSQL como destinos de migração.

Para a maioria das migrações de banco de dados de médio a grande porte, usar o DMS basta. Situações em que o DMS talvez não seja apropriado incluem bancos de dados muito grandes (como vários TB de tamanho) ou se você tiver engenheiros do MySQL com conhecimento de replicação e que preferem um controle mais refinado do processo de migração usando a replicação nativa do MySQL.

Se a redução do tempo de inatividade for uma prioridade durante a migração e você tiver engenheiros com experiência em MySQL na sua equipe, a opção de replicar a partir de uma fonte externa (ES) usando a replicação nativa baseada em registros binários é uma opção. Esse método utiliza a importação de um snapshot de valor de referência do seu banco de dados usando um método como uma importação do Cloud Storage.

Em seguida, você configura a replicação do MySQL na instância de origem para a instância de destino no Cloud SQL usando um conjunto de procedimentos armazenados pré-criados, já disponíveis na instância do Cloud SQL. Veja as instruções completas no artigo Usar uma importação personalizada para configurar a replicação a partir de bancos de dados externos grandes.

Um detalhe importante ao usar replicação com base em registros binários para migração é que os registros binários na instância de origem permanecem disponíveis até que não sejam mais necessários para a instância de destino do Cloud SQL. Ao executar o MySQL no local ou autogerenciado, parâmetros como expire_logs_days podem ser configurados para controlar a limpeza de registros binários. No entanto, outros serviços gerenciados de fornecedores de nuvem têm a própria restrição na retenção de registros binários.

Por exemplo, o Amazon Relational Database Service (RDS) permite configurar a retenção de registros binários por um nome de procedimento armazenado mysql.rds_set_configuration. Isso permite a retenção por até sete dias. Na maioria dos casos, sete dias é suficiente para a maioria das migrações de pequeno a médio porte do RDS para o Cloud SQL. Nessas situações, os usuários podem aproveitar um processo bem documentado que envolve a criação de uma réplica de RDS gerenciada. Em seguida, faça algo para "quebrar" a replicação, por exemplo, tornando a réplica gravável e excluindo uma linha ou injetando algum tipo de transação de "pílula venenosa" na instância primária que entra no registro binário e interrompe a replicação. A automação do RDS não limpará os registros binários enquanto a réplica ainda precisar deles, embora pareça haver um limite geral de 30 dias antes que o RDS "encerre" um stream de replicação corrompido.

Outra solução alternativa é usar o cliente mysqlbinlog para fazer o download de registros binários em outra instância intermediária do MySQL para evitar a limpeza prematura dos registros binários. Por exemplo, no RDS, há um procedimento armazenado chamado mysql.rds_set_configuration que permite definir um período de armazenamento em horas para garantir que os registros binários permaneçam no host tempo o suficiente para download. Nesse caso, você não precisa colocar uma instância do MySQL como intermediário, já que qualquer servidor, como um "servidor do Binlog", que parece uma instância do MySQL, está ali para armazenar e encaminhar registros binários.

O MySQL é exclusivo entre os sistemas de banco de dados relacional mais conhecidos, porque é compatível com vários mecanismos de armazenamento conectáveis. Originalmente, o MySQL aceitava um único mecanismo de armazenamento conhecido como MyISAM e, até o MySQL 8.0, a maioria das tabelas do sistema usava esse mecanismo de armazenamento. No entanto, o MyISAM não era compatível com transações e não tinha segurança durante uma falha repentina do sistema ou de um banco de dados.

Desde então, o InnoDB se tornou o mecanismo de armazenamento real para a maioria das tabelas de usuários do MySQL devido à arquitetura de segurança contra falhas e ao suporte para transações. Ainda assim, existem outros mecanismos de armazenamento comumente vistos na comunidade MySQL, tanto no local quanto em outros provedores de nuvem, como os seguintes:

• ARCHIVE - Armazena dados em um formato altamente compactado para fins de arquivamento
• CSV: armazena dados em formato separado por vírgulas (CSV) e é usado para gerar tabelas de registros de consultas gerais e lentas.
• MEMORY: armazena tabelas na memória

No caso do Cloud SQL, exigimos que um mecanismo de armazenamento transacional e seguro contra falhas ofereça suporte a recursos de valor agregado, como replicação e recuperação pontual. Por isso, todas as tabelas de usuário que são migradas para o Cloud SQL precisam usar o mecanismo de armazenamento do InnoDB ou ser convertidas em InnoDB durante o processo de migração.

Isso é muito importante se você fizer a replicação nativa do MySQL de uma fonte externa para o Cloud SQL. Embora o Cloud SQL não permita que os usuários criem uma tabela MyISAM diretamente em uma instância do Cloud SQL por meio de comandos da linguagem de definição de dados (DDL, na sigla em inglês), como CREATE TABLE, atualmente é possível que as tabelas MyISAM sejam replicadas de uma fonte externa para o Cloud SQL.

No entanto, essas tabelas MyISAM importadas no Cloud SQL podem levar a problemas de estabilidade e confiabilidade posteriormente durante operações como replicação, recuperação pontual e failover. Por esse motivo, é recomendável converter todas as tabelas de usuários do MyISAM em InnoDB antes de realizar uma migração. 

A consulta a seguir lista todas as tabelas MyISAM que não são do sistema.

Por ser um serviço gerenciado, o MySQL para Cloud SQL não permite o privilégio SUPER para contas de usuários. Isso é diferente da maioria das instalações locais do MySQL que permitem a um usuário raiz esse privilégio. Da mesma forma, a maioria dos outros provedores de nuvem não fornece esse privilégio SUPER em um ambiente MySQL gerenciado.

Seja qual for o caso no Cloud SQL, os usuários recebem um usuário padrão do MySQL chamado "root'@'%' que concede a maioria dos privilégios concedidos pelo MySQL, exceto os que afetariam a capacidade do Google de gerenciar o serviço, como o SUPER mencionado acima, além do FILE e SHUTDOWN. Para mais detalhes sobre os privilégios de usuário fornecidos no Cloud SQL, consulte a documentação sobre usuários do MySQL.

Ao se preparar para migrar, revise todas as contas de usuário na instância de origem. Por exemplo, execute o comando SHOW GRANTS para que cada usuário analise o conjunto atual de privilégios e veja se há algum restrito no Cloud SQL. Da mesma forma, a ferramenta pt-show-grants da Percona também pode listar as concessões.

As restrições nos privilégios de usuário no Cloud SQL podem afetar as migrações ao migrar objetos de banco de dados que têm um atributo DEFINER. Isso geralmente se aplica a procedimentos armazenados, gatilhos, funções definidas pelo usuário e visualizações. Se o definidor de um objeto de banco de dados na instância de origem for um usuário com um privilégio não compatível com o Cloud SQL, isso poderá ser um problema durante ou após a migração.

Por exemplo, um procedimento armazenado pode ter um definidor muito privilegiado para executar comandos SQL, como alterar uma variável global que não é permitida no Cloud SQL. Para casos como esse, pode ser necessário reescrever o código de procedimento armazenado ou migrar objetos que não sejam de tabela, como procedimentos armazenados, como uma etapa de migração separada.

Na nossa documentação, há uma seção chamada Jobs de importação e migração do MySQL contendo metadados com a cláusula DEFINER, que fala um pouco mais sobre outros problemas relacionados à cláusula do definidor para objetos de banco de dados.

Devido às restrições de privilégio de usuário mencionadas anteriormente, os usuários não podem chamar o comando SET GLOBAL de forma nativa para alterar os parâmetros do banco de dados. Em vez disso, o Cloud SQL oferece um conjunto predefinido de "sinalizações" que podem ser modificadas no Console da IU, na CLI do GCloud e na API REST para modificar os parâmetros.

A lista completa de sinalizações do Cloud SQL compatíveis com o MySQL pode ser encontrada na nossa documentação pública na seção Sinalizações compatíveis. Antes de migrar para o Cloud SQL, veja a lista de sinalizações compatíveis vs. as sinalizações usadas atualmente no ambiente de origem. Por exemplo, uma prática recomendada é criar uma instância de teste do Cloud SQL com configurações semelhantes de CPU e memória como a instância de origem e executar SHOW GLOBAL VARIABLES na instância de origem e na do Cloud SQL e comparar as diferenças.

As sinalizações comuns que podem ter configurações diferentes no local ou em um provedor de nuvem e no Cloud SQL para MySQL incluem o seguinte:

• Conjunto de caracteres e configurações de ordenação, como character_set_server e collation_server. Os padrões podem diferir entre as instalações e levar a diferenças de armazenamento e desempenho. Por exemplo, latin1 e utf8.
• Configurações de registro binário, como binlog_format. No momento, o Cloud SQL é compatível apenas com a geração de registros baseada em linha no registro binário.
• Configurações de replicação avançadas. Por exemplo, o Cloud SQL não oferece suporte a parâmetros de filtro de replicação, como replicate-do-table e replicate-do-db:
• Configurações avançadas do InnoDB. O Cloud SQL permite modificar a maioria dos parâmetros relacionados ao InnoDB, como redimensionar o pool de buffer do InnoDB mudando innodb_buffer_pool_size. No entanto, pode haver algumas configurações mais detalhadas do InnoDB que não podem ser modificadas no Cloud SQL ou com padrões diferentes daqueles no local ou de outros provedores de nuvem.