ApsaraDB RDS:Upgrade the database version

Selecione um método de atualização

Tanto o Método 1: Atualizar diretamente a versão do banco de dados no console quanto o Método 2: Atualizar a versão do banco de dados usando o DTS suportam os seguintes caminhos de atualização do MySQL: 5,5 para 5,6, 5,6 para 5,7 e 5,7 para 8,0. Antes de iniciar a atualização, escolha o método mais adequado com base nas informações abaixo:

• Se sua instância pertencer a uma das quatro categorias a seguir e atender aos requisitos correspondentes, utilize o Método 1: Atualizar diretamente a versão do banco de dados no console.

  Nota

  • Instâncias Serverless não permitem atualização direta pelo console. Nesse caso, use o Método 2: Atualizar a versão do banco de dados usando o DTS.

  • Atualizações do MySQL 8,0 para o MySQL 8.4 não são suportadas via console. Para esse caminho de atualização, adote o Método 2: Atualizar a versão do banco de dados usando o DTS.

  Cluster Edition (ESSD and premium performance disk)

  • Restrição de replicação em grupo: Não é possível atualizar instâncias Cluster Edition que utilizam MySQL Group Replication (MGR).

  • Restrição de proxy de banco de dados (se aplicável): A versão secundária do proxy de banco de dados deve ser 1.13.41 ou superior.

  • Restrição de status da instância: O status da instância deve ser Running, e os nós primário e secundário devem estar íntegros, sem atraso de replicação.

  • Restrição de mecanismo: O banco de dados e todas as suas tabelas devem usar o mecanismo de armazenamento InnoDB.

  • A instância não deve utilizar um tipo de instância descontinuado.

  High-availability Edition (ESSD and premium performance disk)

  • Restrição de proxy de banco de dados (se aplicável): A versão secundária do proxy de banco de dados deve ser 1.13.41 ou superior.

  • Restrição de status da instância: O status da instância deve ser Running, e os nós primário e secundário devem estar íntegros, sem atraso de replicação.

  • Restrição de mecanismo: O banco de dados e todas as suas tabelas devem usar o mecanismo de armazenamento InnoDB.

  • A instância não deve utilizar um tipo de instância descontinuado.

  High-availability Edition (premium performance local disk)

  • Restrição de criptografia: O recurso de criptografia transparente de dados (TDE) deve estar desativado. Uma vez ativado, o TDE não pode ser desativado. Se o TDE estiver habilitado na sua instância, use o Método 2: Atualizar a versão do banco de dados usando o DTS.

  • Restrição de proxy de banco de dados (se aplicável): A versão secundária do proxy de banco de dados deve ser 1.13.41 ou superior.

  • Restrição de status da instância: O status da instância deve ser Running, e os nós primário e secundário devem estar íntegros, sem atraso de replicação.

  • Restrição de quantidade de tabelas: O número de tabelas não pode exceder 1 milhão.

  • Restrição de mecanismo: O banco de dados e todas as suas tabelas devem usar o mecanismo de armazenamento InnoDB.

  • Restrição de tipo de instância: A versão do banco de dados após a atualização deve suportar os tipos de instância originais das instâncias primárias e somente leitura. As instâncias não devem usar um tipo descontinuado. Para mais informações, consulte Tipos de instância primária do ApsaraDB RDS for MySQL.

  Basic Edition (ESSD and premium performance disk)

  • Restrição de status da instância: O status da instância deve ser Running.

  • Restrição de mecanismo: O banco de dados e todas as suas tabelas devem usar o mecanismo de armazenamento InnoDB.

  • A instância não deve utilizar um tipo de instância descontinuado.

• Caso sua instância não pertença a nenhuma das quatro categorias anteriores ou se o TDE estiver habilitado, opte pelo Método 2: Atualizar a versão do banco de dados usando o DTS.

• Se sua instância pertencer a uma das quatro categorias anteriores, mas não atender aos requisitos de configuração, ajuste a configuração conforme descrito na tabela a seguir. Em seguida, utilize o Método 1: Atualizar diretamente a versão do banco de dados no console ou o Método 2: Atualizar a versão do banco de dados usando o DTS.

  Problema	Solução
  O status da instância não é Running; por exemplo, está como Restarting.	Aguarde a conclusão da tarefa atual antes de atualizar a versão do banco de dados.
  O número de tabelas em uma instância High-availability Edition com disco local de alto desempenho excede 1 milhão.	Exclua as tabelas redundantes antes da atualização.
  Alguns bancos de dados ou tabelas não usam o mecanismo InnoDB.	Execute o comando ALTER TABLE <table_name> engine=InnoDB; para alternar para o mecanismo InnoDB.
  A instância usa um tipo de instância descontinuado.	Atualize o tipo da instância antes de atualizar a versão do banco de dados. Para mais informações, consulte Alterar configuração.
  A versão secundária do proxy de banco de dados não atende aos requisitos.	Atualize a versão secundária do proxy de banco de dados para 1.13.41 ou superior. Para mais informações, consulte Atualizar a versão secundária do mecanismo de um proxy de banco de dados.
  O tipo de armazenamento da instância é SSD padrão.	Primeiro, atualize o SSD padrão para um SSD empresarial (ESSD) e, em seguida, atualize a versão do banco de dados.

Para atualizar a versão principal do banco de dados de outros mecanismos, consulte os tópicos a seguir:

• Atualizar a versão principal do banco de dados de uma instância ApsaraDB RDS for PostgreSQL

• Atualizar a versão principal do banco de dados de uma instância ApsaraDB RDS for SQL Server

Método 1: Atualizar diretamente a versão do banco de dados no console

Método 2: Atualizar a versão do banco de dados usando o DTS

Para instâncias que não suportam atualização direta pelo console, crie uma nova instância com uma versão mais recente do banco de dados. Em seguida, use uma tarefa de migração de dados do DTS para migrar os dados da instância original para a nova. Isso atualiza a versão do banco de dados indiretamente. O processo envolve as seguintes etapas:

1. Criar uma nova instância

2. Migrar dados para a nova instância

3. Liberar a instância original

Exemplo: Suponha que você tenha uma instância MySQL 5,7 com TDE habilitado, que não pode ser atualizada diretamente pelo console. Nesse caso, crie uma nova instância executando o MySQL 8,0, migre os dados da instância original para a nova e, finalmente, libere a instância original. Isso atualiza a versão do banco de dados indiretamente.

Apêndice 1: Benefícios da atualização do MySQL 5,7 para o MySQL 8,0

• Melhora a segurança e oferece maior flexibilidade no gerenciamento de contas.

• Suporta a criação e o gerenciamento de grupos de recursos.

• Aprimora os recursos do mecanismo de armazenamento InnoDB.

• Adiciona suporte a novos conjuntos de caracteres, tipos de dados, sintaxe, novos bloqueios de backup e sinalizadores optimizer_switch.

• Aprimora a funcionalidade JSON e XML.

• Aprimora os recursos do otimizador.

• Melhora o desempenho da replicação.

• Suporta a criação de índices multivalorados e otimização de pushdown de condições derivadas.

• Suporta a leitura de tabelas de concessão do MySQL.

• Suporta controle de alocação de recursos.

Apêndice 2: Benefícios da atualização do MySQL 5,6 para o MySQL 5,7

• Adiciona recursos como gerenciamento de senhas, bloqueio de contas e conexões criptografadas para melhorar a segurança do banco de dados.

• Suporta operações DDL online, como renomear um índice usando RENAME INDEX.

• Melhora a escalabilidade do mecanismo InnoDB e o desempenho de tabelas temporárias para carregamento de dados mais rápido.

• Suporta JSON.

• Suporta Index Condition Pushdown (ICP) para tabelas particionadas e novos índices espaciais InnoDB.

• Otimiza a maioria dos analisadores, otimizadores e modelos de custo para melhorar a manutenibilidade, escalabilidade e desempenho do banco de dados.

• Expande a variedade de conjuntos de caracteres suportados, incluindo o conjunto de caracteres GB18030 especificado pelo padrão nacional chinês.

• Fornece o plugin de analisador de texto completo ngram, que suporta chinês, japonês e coreano.

• Otimiza threads de dump de source para reduzir a contenção de bloqueios e aumentar o throughput da source.

• Reduz significativamente o atraso de replicação.

• Adiciona o banco de dados de sistema sys, que fornece várias métricas e reduz o uso de armazenamento, melhorando significativamente a usabilidade do banco de dados.

Apêndice 3: Diferenças de recursos entre MySQL 8,0 e MySQL 5,7

Apêndice 4: Diferenças de recursos entre MySQL 5,7 e MySQL 5,6

Apêndice 5: Diferenças de recursos entre MySQL 5,5 e MySQL 5,6

Perguntas frequentes

• P: Por que ocorre um switchover de instância durante a atualização? Existem outros riscos graves?

  R: Para garantir a estabilidade do service, instâncias com discos locais de alto desempenho são atualizadas primeiro atualizando o nó secundário e depois realizando um switchover. Instâncias com ESSDs são atualizadas criando um novo nó e depois realizando um switchover. Não há outros riscos graves. Para mais informações sobre o impacto de um failover primário/secundário, consulte Impacto de um failover primário/secundário.

• P: Os nós primário e secundário são atualizados ao mesmo tempo?

  R: Ao atualizar um disco local de alto desempenho, a instância secundária é atualizada primeiro, seguida pela instância primária.

• P: Como atualizo uma instância Basic Edition executando MySQL 5,7 com SSDs padrão?

  R: Não é possível atualizar esse tipo de instância diretamente. Para atualizar uma instância Basic Edition executando MySQL 5,7 com SSDs padrão, você deve primeiro alterar o tipo de armazenamento de SSD padrão para ESSD e, em seguida, atualizar a versão do banco de dados.

• P: O modelo de parâmetros é mantido após a atualização da versão do banco de dados?

  R: Depende. Se a instância usar um modelo de parâmetros do sistema antes da atualização, ela será automaticamente trocada para o modelo de parâmetros do sistema correspondente à nova versão. Por exemplo, uma instância usando o modelo de parâmetros MySQL_InnoDB_5.7_High-availability_Performance é trocada para o modelo de parâmetros MySQL_InnoDB_8.0_High-availability_Performance após uma atualização do MySQL 5,7 para o 8,0. No entanto, se a instância usar um modelo de parâmetros personalizado, o modelo de parâmetros não será mantido após a atualização.

• P: Posso modificar a instância durante a atualização da versão do banco de dados?

  R: Não, não é possível. Você só pode realizar outras operações na instância após a conclusão da atualização.

• P: A versão do banco de dados suporta atualizações automáticas?

  R: Não. Atualizações automáticas de versão principal não são suportadas.

• P: Posso fazer downgrade da versão do banco de dados?

  R: Não é possível fazer downgrade direto da versão pelo console. Selecione um dos métodos a seguir com base na existência de dados comerciais na instância:

  • Com dados comerciais: Adquira uma instância que execute uma versão anterior, use o DTS para migrar dados da instância de versão superior para a nova instância de versão inferior e, em seguida, libere a instância de versão superior após a conclusão da migração. Isso faz o downgrade da versão do banco de dados indiretamente. Para mais informações, consulte Migração de dados entre instâncias RDS.

  • Sem dados comerciais: Cancele a assinatura da instância original e adquira uma nova instância que execute a versão anterior desejada. Para instâncias por assinatura, siga o processo de reembolso para cancelar. Para instâncias de pagamento conforme o uso, libere-as diretamente.

• P: Ao atualizar uma instância RDS for MySQL de 5,6 para 5,7 ou de 5,7 para 8,0, a atualização falha. É exibida a mensagem "The current instance has a full-text index and its minor version is earlier than 20221130. Please upgrade the minor version before deleting and rebuilding the full-text index" ou "The current instance contains a full-text index built in the system tablespace. Please delete and rebuild the corresponding full-text index before proceeding with the upgrade." Qual é a causa e a solução?

  R: A causa e a solução são as seguintes:

  • Causa

    Devido a um problema histórico no MySQL, ao criar um índice de texto completo em uma versão antiga do MySQL 5,6, ele é construído no tablespace do sistema. Ao atualizar para a versão 5,7 ou 8,0, um índice de texto completo no tablespace do sistema pode causar corrupção do tablespace. Portanto, você deve resolver esse problema antes da atualização para evitar corrupção de dados e inacessibilidade.

    Nota

    Esse problema foi corrigido na versão 20221130 do RDS for MySQL 5,6. Índices de texto completo agora são construídos em um tablespace separado.

  • Solução

    Importante

    Índices de texto completo em versões anteriores do RDS for MySQL 5,6 são criados no tablespace do sistema. Portanto, certifique-se de que a versão da qual você está atualizando seja RDS for MySQL 5,6 20221130 ou posterior antes de atualizar para o RDS for MySQL 5,7. Se estiver usando uma versão anterior, atualize para a versão mais recente do RDS for MySQL 5,6 primeiro.

    1. Com base no nome da tabela no aviso, exclua o índice de texto completo que foi construído no tablespace do sistema.

       # Delete the full-text index.
       ALTER TABLE $table_name DROP INDEX $fts_name;

    2. Recrie o índice de texto completo.

       # Re-create the full-text index.
       ALTER TABLE $table_name ADD FULLTEXT INDEX $fts_name;

    3. Após criar o índice, execute a seguinte instrução SQL para verificar os índices de texto completo na instância atual. A instrução retorna quaisquer índices de texto completo construídos no tablespace do sistema. Se a consulta retornar um resultado vazio, a atualização do RDS for MySQL 5,6 para o RDS for MySQL 5,7 não falhará devido a esse problema.

       # Query for full-text indexes built in the system tablespace.
       SELECT NAME FROM information_schema.INNODB_SYS_TABLES WHERE TABLE_ID IN ( SELECT CONV(SUBSTRING_INDEX(SUBSTRING_INDEX(NAME, '_', -4),'_', 1),16,10) FROM INNODB_SYS_TABLES WHERE NAME LIKE '%fts_00000000%' AND SPACE = 0);

• P: Ao atualizar uma instância RDS for MySQL de 5,7 para 8,0, o erro 267 - Illegal mix of collations (utf8mb4_general_ci,IMPLICIT) and (utf8mb4_0900_ai_ci,IMPLICIT) for operation '=' é relatado. Como lidar com isso?

  R: Verifique o conjunto de caracteres e a intercalação no MySQL. Se estiver usando utf8mb4_general_ci, execute as seguintes instruções SQL para alterá-lo para utf8mb4_0900_ai_ci.

  # Modify the character set and collation of the database.
  ALTER DATABASE database_name CHARACTER SET = utf8mb4 COLLATE = utf8mb4_0900_ai_ci;
  # Modify the character set and collation of the table.
  ALTER TABLE table_name CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;
  # Modify the character set and collation of the field.
  ALTER TABLE table_name CHANGE column_name column_name type CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci;

  Se você criar uma tabela com a intercalação utf8mb4_general_ci no MySQL 5,7 e depois atualizar para o MySQL 8,0, o sistema usará utf8mb4_0900_ai_ci como a intercalação padrão. Se executar uma consulta que compare uma coluna usando utf8mb4_general_ci com uma coluna usando utf8mb4_0900_ai_ci, o MySQL não conseguirá processar as duas intercalações diferentes, resultando em um erro.

• P: O tempo de conexão transitória para uma atualização de versão principal é sempre de 15 segundos, independentemente da existência de instâncias somente leitura?

  R: Sim, é. Recomendamos realizar a atualização fora dos horários de pico.

Operações de API relacionadas