ApsaraDB RDS:[Descontinuado] Converter o mecanismo TokuDB para o mecanismo InnoDB

Contexto

A Percona descontinuou o suporte ao TokuDB. Consequentemente, bugs conhecidos não serão corrigidos e podem causar interrupções nos negócios. Por esse motivo, a Alibaba Cloud removeu o suporte ao mecanismo de armazenamento TokuDB no ApsaraDB RDS for MySQL em 1º de agosto de 2019. A conversão direta do mecanismo de armazenamento bloqueia operações DML e pode afetar a concorrência. Avalie seus requisitos de negócios e escolha uma das soluções a seguir para converter os dados.

Data de descontinuação do mecanismo TokuDB

1º de agosto de 2019

Aplicabilidade

Instâncias que utilizam o mecanismo de armazenamento TokuDB.

Precauções

• A conversão do mecanismo de armazenamento aumenta o uso de espaço. Reserve espaço livre equivalente a aproximadamente duas vezes o tamanho das tabelas TokuDB em conversão. Monitore atentamente o uso de armazenamento durante a operação.

• Após a conversão, a utilização da CPU diminui, mas o IOPS aumenta. Como as páginas de dados não são compactadas, ler a mesma quantidade de dados exige mais operações de I/O.

• Ao executar uma migração completa, alterne o endpoint da aplicação. Recomendamos essa operação em horários de baixa demanda para minimizar o impacto nos negócios.

• Se alterar a versão do banco de dados durante uma migração completa, faça um teste de compatibilidade antecipadamente.

Soluções recomendadas

• Use a Solução 1 se suas tabelas forem pequenas (menos de 100 MB) e sua aplicação tolerar um curto período de inatividade. Esse método tem um tempo breve de bloqueio de tabela e evita configurações complexas de ferramentas.

• Prefira a Solução 2 ou Solução 3 se suas tabelas forem grandes (mais de 5 GB).

• Escolha a Solução 3 ou Solução 4 caso precise converter todas as tabelas da instância.

• Após converter o mecanismo, altere o parâmetro de instância default_storage_engine para InnoDB.

Solução 1

Essa solução converte o mecanismo diretamente por meio de uma instrução ALTER TABLE. É o método mais simples, mas bloqueia operações DML na tabela, o que pode ser demorado para tabelas grandes.

1. Log on to the ApsaraDB RDS database by using Data Management (DMS).

2. Na barra de navegação superior, escolha sql operations > sql window.

3. Execute o seguinte comando:

   ALTER TABLE test.testfs ENGINE=innodb;

   Execute SQL: (1)
   Alter table test.testfs engine innodb
   Execution successful. Time elapsed: [18185ms.]

Solução 2

Essa solução utiliza uma ferramenta de alteração de schema online de terceiros para converter os dados com tempo de inatividade mínimo. Muitas ferramentas suportam DDL online, como o pt-osc da Percona e o gh-ost do GitHub. Esta seção usa o gh-ost como exemplo. Para informações detalhadas, consulte a documentação oficial do gh-ost.

Como funciona

Parâmetros

Pré-requisitos

• O gh-ost está instalado no host local ou na instância do Elastic Compute Service (ECS).

• O endereço IP do host local ou da instância ECS foi adicionado à lista de permissões de endereços IP da instância do ApsaraDB RDS.

Procedimento

1. No host local ou na instância ECS, execute o seguinte comando para iniciar a conversão e aguarde a conclusão do processo.

   gh-ost --user="test01" --password="Test123456" --host="rm-bpxxxxx.mysql.rds.aliyuncs.com"  --database="test" --table="testfs"  --alter="engine=innodb" --initially-drop-old-table --initially-drop-ghost-table --aliyun-rds --assume-rbr --allow-on-master --assume-master-host="rm-bpxxxxx.mysql.rds.aliyuncs.com" --chunk-size=500 --postpone-cut-over-flag-file="/tmp/ghostpost.postpone" --panic-flag-file="/tmp/stop.flag" --serve-socket-file="/tmp/ghost.sock" --execute

   2019/06/13 17:22:51 binlogsyncer.go:79: [info] create BinlogSyncer with config {999
   2019/06/13 17:22:51 binlogsyncer.go:246: [info] begin to sync binlog from position
   2019/06/13 17:22:51 binlogsyncer.go:139: [info] register slave for master server rm
   2019/06/13 17:22:51 binlogsyncer.go:573: [info] rotate to (mysql-bin.000014, 241268
   # Migrating `test`.`testfs`; Ghost table is `test`.`_testfs_gho`
   # Migrating `xxx`.`xxx`; xxx xxx rds.aliyuncs.com:3306; inspecting xxx
   # Migration started at Thu Jun 13 17:22:50 +0800 2019
   # chunk-size: 500; max-lag-millis: 1500ms; dml-batch-size: 10; max-load: ; critical
   # throttle-additional-flag-file: /tmp/gh-ost.throttle
   # postpone-cut-over-flag-file: /tmp/ghostpost.postpone [set]
   # panic-flag-file: /tmp/stop.flag
   # Serving on unix socket: /tmp/ghost.sock
   Copy: 0/100000 0.0%; Applied: 0; Backlog: 0/1000; Time: 0s(total), 0s(copy); stream
   Copy: 0/100000 0.0%; Applied: 0; Backlog: 0/1000; Time: 1s(total), 1s(copy); stream
   Copy: 1500/100000 1.5%; Applied: 0; Backlog: 0/1000; Time: 2s(total), 2s(copy); str
   Copy: 3000/100000 3.0%; Applied: 0; Backlog: 0/1000; Time: 3s(total), 3s(copy); str
   Copy: 5500/100000 5.5%; Applied: 0; Backlog: 0/1000; Time: 4s(total), 4s(copy); str
   Copy: 7500/100000 7.5%; Applied: 0; Backlog: 0/1000; Time: 5s(total), 5s(copy); str
   Copy: 9000/100000 9.0%; Applied: 0; Backlog: 0/1000; Time: 6s(total), 6s(copy); str
   Copy: 10500/100000 10.5%; Applied: 0; Backlog: 0/1000; Time: 7s(total), 7s(copy); s
   Copy: 13500/100000 13.5%; Applied: 0; Backlog: 0/1000; Time: 8s(total), 8s(copy); s
   Copy: 15500/100000 15.5%; Applied: 0; Backlog: 0/1000; Time: 9s(total), 9s(copy); s
   Copy: 17500/100000 17.5%; Applied: 0; Backlog: 0/1000; Time: 10s(total), 10s(copy);

2. Log on to the ApsaraDB RDS database by using Data Management (DMS).

3. No painel de navegação à esquerda, visualize as tabelas. Tabelas temporárias terminadas com _gho e _ghc estarão visíveis. Após fazer login, na lista de tabelas do banco de dados test, verifique as tabelas temporárias _testfs_ghc e _testfs_gho criadas pelo gh-ost, indicando que a conversão está em andamento.

4. Execute o comando rm /tmp/ghostpost.postpone para iniciar o cutover da tabela. A seguinte saída será exibida.

   Copy: 100000/100000 100.0%; Applied: 0; Backlog: 0/1000; Time: 9m0s(total), 56s(copy); streamer: mysql-bin.000015:520562237;
   Copy: 100000/100000 100.0%; Applied: 0; Backlog: 0/1000; Time: 9m30s(total), 56s(copy); streamer: mysql-bin.000015:520674422;
   # Migrating `test`.`testfs`; Ghost table is `test`.`_testfs_gho`
   # Migrating xxx xxx xxx mysql.rds.aliyuncs.com:3306; inspecting xxx xxx xxx xxx mysql.rds.aliyuncs.com:3306
   # Migration started at Thu Jun 13 17:22:50 +0800 2019
   # chunk-size: 500; max-lag-millis: 1500ms; dml-batch-size: 10; max-load: ; critical-load: ; nice-ratio: 0.000000
   # throttle-additional-flag-file: /tmp/gh-ost.throttle
   # postpone-cut-over-flag-file: /tmp/ghostpost.postpone
   # panic-flag-file: /tmp/stop.flag
   # Serving on unix socket: /tmp/ghost.sock
   Copy: 100000/100000 100.0%; Applied: 0; Backlog: 0/1000; Time: 9m31s(total), 56s(copy); streamer: mysql-bin.000015:520681377;
   2019/06/13 17:32:23 binlogsyncer.go:107: [info] syncer is closing...
   2019/06/13 17:32:23 binlogstreamer.go:47: [error] close sync with err: sync is been closing...
   2019/06/13 17:32:23 binlogsyncer.go:122: [info] syncer is closed

   Nota

   Ignore a mensagem de erro na saída. O cutover foi concluído.

5. Verifique o schema da tabela e valide os dados.

   Nota

   Após confirmar que os dados estão corretos, exclua a tabela _del.

   Execute show create table para visualizar o schema da tabela e confirmar que o valor AUTO_INCREMENT é 100001, o que indica que todos os dados foram retidos.

Solução 3

Essa solução utiliza o Data Transmission Service (DTS) da Alibaba Cloud para sincronizar dados da tabela original para uma tabela temporária com o mecanismo InnoDB. Em seguida, renomeie a tabela durante horários de baixa demanda. Essa abordagem é adequada para converter um grande número de tabelas simultaneamente.

1. Log on to the ApsaraDB RDS database by using Data Management (DMS).

2. Na barra de navegação superior, escolha sql operations > sql window.

3. Execute o seguinte comando para criar uma tabela temporária com o mecanismo InnoDB:

   CREATE TABLE `testfs_tmp` (
     `id` int(11) NOT NULL AUTO_INCREMENT,
     `vc` varchar(8000) DEFAULT NULL,
     PRIMARY KEY (`id`)
   ) ENGINE=innodb  DEFAULT CHARSET=utf8;
                       

4. Purchase a data synchronization instancePurchase a data synchronization instance.

   Nota

   As instâncias de sincronização de dados são um service pago. Para mais informações, consulte Preços do Data Transmission Service.

5. No painel de navegação à esquerda do console do DTS, clique em Data Synchronization.

6. Localize a instância de sincronização de dados adquirida e clique em Configure Task na coluna Actions.

7. Configure as instâncias de source e destino.

   Seção	Parâmetro	Descrição
   Detalhes da instância de source	Tipo de instância	Selecione RDS Instance.
   	ID da instância	Selecione a instância RDS que contém as tabelas TokuDB a serem convertidas.
   	Criptografia	Selecione Non-encrypted ou SSL-encrypted. Caso selecione SSL-encrypted, ative primeiro o SSL encryption. Esta opção aumenta significativamente a utilização da CPU.
   Detalhes da instância de destino	Tipo de instância	Selecione RDS Instance.
   	ID da instância	Selecione a instância RDS que contém as tabelas TokuDB a serem convertidas.
   	Criptografia	Selecione Non-encrypted ou SSL-encrypted. Caso selecione SSL-encrypted, ative primeiro o SSL encryption. Esta opção aumenta significativamente a utilização da CPU.

   A página também inclui um campo Synchronization job name e uma lista suspensa Instance region (por exemplo, China (Hangzhou)). Após configurar, clique em Test Connectivity and Proceed.

8. Clique em Test Connectivity and Proceed.

9. Aguarde a criação da conta de sincronização e clique em Next.

10. Configure os objetos de sincronização: Defina Synchronization type como One-way synchronization (DML+DDL) e defina o Processing mode for existing destination tables como Pre-check and report errors. No painel Source objects à esquerda, selecione a tabela testfs no banco de dados test002, mova-a para o painel Selected objects à direita, passe o mouse sobre o objeto e clique em Edit.

11. Altere o Database Name para o testfs_tmp criado anteriormente e clique em OK.

12. Clique em Next.

13. Selecione apenas initial full data synchronization (não selecione Schema migration) e clique em Precheck.

14. Aguarde a conclusão da pré-verificação e clique em Close.

15. Aguarde até que a latência de sincronização de dados seja 0 ms. O status da tarefa de sincronização muda para Synchronizing, indicando que a sincronização de dados começou.

16. Na janela SQL do DMS, execute o seguinte comando para alternar os nomes das tabelas:

    RENAME TABLE `testfs` TO `testfs_del`, `testfs_tmp` TO `testfs`;

    Nota

    • Após a troca das tabelas, a tarefa do DTS relatará um erro. Esse comportamento é esperado.

    • Depois de validar os dados, libere a instância de sincronização de dados o mais rápido possível para evitar cobranças adicionais.

Solução 4

Essa solução utiliza o DTS para migrar completamente o banco de dados para uma nova instância. Tal abordagem é adequada se você também planeja atualizar a instância ou se sua aplicação tolerar um tempo de inatividade maior para o cutover.

1. Exporte o schema como instruções CREATE TABLE da instância de source. No script, modifique a cláusula ENGINE de cada tabela.

   Nota

   Por exemplo, altere create table t1(id int,name varchar(10)) engine=tokudb; para create table t1(id int,name varchar(10)) engine=innodb;.

2. Create an ApsaraDB RDS for MySQL instance e execute o script modificado para criar o banco de dados e as tabelas com o mecanismo InnoDB.

3. Use o DTS para synchronize data from the source instance to the new instancesynchronize data from the source instance to the new instance.

   Nota

   Ao configurar a tarefa do DTS, selecione apenas initial full data synchronization.

4. Após confirmar que a latência de sincronização é zero, alterne o endpoint da aplicação para a nova instância.