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, 5,7 para 8,0 e 8,0 para 8,4. Antes de iniciar a atualização do banco de dados, 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 sua configuração atender aos requisitos correspondentes, use o Método 1: Atualizar diretamente a versão do banco de dados no console.

  Nota

  Instâncias Serverless não suportam atualizações diretas pelo console. Use 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 de grupo: Não é possível atualizar instâncias da Cluster Edition que usam MySQL Group Replication (MGR).

  • Restrição de proxy de banco de dados (se aplicável): Para atualizações da versão 5,7 para 8,0, a versão secundária do proxy de banco de dados deve ser 1.13.41 ou superior. Para atualizações da versão 8,0 para 8,4, a versão secundária do proxy deve ser 2.25.11 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 usar 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): Para atualizações da versão 5,7 para 8,0, a versão secundária do proxy de banco de dados deve ser 1.13.41 ou superior. Para atualizações da versão 8,0 para 8,4, a versão secundária do proxy deve ser 2.25.11 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 usar 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. Após ativar o TDE, não é possível desativá-lo. Se o TDE estiver ativado em 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): Para atualizações da versão 5,7 para 8,0, a versão secundária do proxy de banco de dados deve ser 1.13.41 ou superior. Para atualizações da versão 8,0 para 8,4, a versão secundária do proxy deve ser 2.25.11 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 usar 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 ativado, use o 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 a configuração não atender aos requisitos, modifique a configuração conforme descrito na tabela a seguir. Em seguida, use 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 da 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 ESSD empresarial e depois atualize a versão do banco de dados.

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

• 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 de banco de dados mais recente. 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. Este 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: Você possui uma instância MySQL 5,7 com TDE ativado, 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 8,0 para o MySQL 8,4

• Maior estabilidade de longo prazo. O MySQL 8,4 é uma versão LTS adequada para uso prolongado em ambientes de produção. As versões subsequentes 8.4.x focam em estabilidade, correções de segurança e manutenção de compatibilidade.

• Autenticação aprimorada. Suporta autenticação WebAuthn/FIDO2. A Enterprise Edition pode usar chaves de segurança, biometria e outros métodos de autenticação. No Windows, há suporte para autenticação SASL LDAP/GSSAPI/Kerberos.

• Capacidades GTID aprimoradas. Suporta GTIDs marcados. Use o formato UUID:TAG:NUMBER para distinguir diferentes domínios de negócios, operações administrativas ou operações de dados, e o privilégio TRANSACTION_GTID_TAG fornece controle de acesso.

• Disponibilidade de replicação melhorada. O aplicador multithread suporta SQL_AFTER_GTIDS, permitindo que a replicação paralela continue quando uma réplica alcança um conjunto GTID especificado.

• Recuperação de relay log aprimorada. Suporta a limpeza de transações incompletas no final do relay log e arquivos residuais relacionados, reduzindo o risco de recuperação causado por inconsistência do relay log após um desligamento anormal.

• Operações de Replicação de Grupo aprimoradas. Dentro da série LTS 8,4, há suporte para membros de grupo entre versões e downgrades in-place. A espera por operações DDL e DCL durante uma troca de primário é mais completa, e a pré-limpeza de informações de autenticação é suportada no modo single-primary para reduzir riscos de memória e de troca.

• Estatísticas melhoradas. Histogramas suportam controle de atualização automática ou manual, o que ajuda a melhorar a controlabilidade da manutenção de estatísticas do otimizador.

• Diagnóstico de plano de execução aprimorado. EXPLAIN FORMAT=JSON suporta seleção de versão de formato, EXPLAIN FORMAT=JSON INTO grava a saída em uma variável de usuário, e EXPLAIN FOR SCHEMA e FOR DATABASE são suportados, facilitando o diagnóstico de SQL entre schemas.

• Validação de certificado TLS aprimorada. Suporta validação de certificado TLS mais rigorosa para melhorar a segurança de conexões criptografadas.

• Clone melhorado. Dentro da mesma série principal ou secundária, a operação de clone não exige mais uma correspondência exata de versão pontual, facilitando a inicialização, recuperação e dimensionamento de instâncias entre versões 8.4.x.

• Auditoria e firewall aprimorados. O Enterprise Firewall suporta recargas periódicas de cache e schemas de objetos internos personalizados para maior flexibilidade operacional.

• Migração de gerenciamento de chaves melhorada. Suporta migração de um componente keyring para um plugin keyring, melhorando a flexibilidade para cenários de migração de criptografia e compatibilidade.

• Observabilidade de atualização melhorada. O diretório de dados mantém um arquivo mysql_upgrade_history no formato JSON que registra o histórico de instalação e atualização para auditoria e solução de problemas.

• Evolução aprimorada de SQL e otimizador. Adiciona palavras-chave como TABLESAMPLE, QUALIFY e PARALLEL para fornecer uma base para futuras extensões de SQL e do otimizador.

Apêndice 2: 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 flags 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ção derivada.

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

• Suporta controle de alocação de recursos.

Apêndice 3: 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 Online DDL, 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 analisador de texto completo ngram, que suporta chinês, japonês e coreano.

• Otimiza threads de dump de source para reduzir contenção de bloqueio e aumentar o throughput do 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 4: Diferenças de recursos entre MySQL 8,4 e MySQL 8,0

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

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

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

FAQ

• P: Por que ocorre uma troca 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 uma troca. Instâncias com ESSDs são atualizadas criando um novo nó e depois realizando uma troca. 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 da Basic Edition executando MySQL 5,7 com SSDs padrão?

  R: Não é possível atualizar diretamente esse tipo de instância. Para atualizar uma instância da 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 depois 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 alternada 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 é alternada para o modelo de parâmetros MySQL_InnoDB_8.0_High-availability_Performance após uma atualização do MySQL 5,7 para 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, não suporta. 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 seguintes métodos com base no fato de a instância conter dados de negócios:

  • Com dados de negócios: 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 de negócios: Cancele a assinatura da instância original e adquira uma nova instância que execute a versão anterior necessária. Para instâncias de assinatura, siga o processo de reembolso para cancelar a assinatura. 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. Ela mostra 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

    Este 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 você 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 este 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 collation no MySQL. Se você 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 collation utf8mb4_general_ci no MySQL 5,7 e depois atualizar para o MySQL 8,0, o sistema usará utf8mb4_0900_ai_ci como a collation padrão. Se você executar uma consulta que compara uma coluna que usa utf8mb4_general_ci com uma coluna que usa utf8mb4_0900_ai_ci, o MySQL não consegue processar as duas collations 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