Todos os produtos
Search

Este produto

    PolarDB:Upgrade com um clique do RDS for MySQL para o PolarDB for MySQL

    Central de documentação

    PolarDB:Upgrade com um clique do RDS for MySQL para o PolarDB for MySQL

    Última atualização: Jun 28, 2026

    PolarDB permite atualizar uma instância ApsaraDB RDS for MySQL para um cluster PolarDB for MySQL com apenas um clique. O PolarDB sincroniza automaticamente contas, bancos de dados, listas de permissões de IP e parâmetros da instância RDS de origem. Mantenha o endpoint original para que as aplicações alternem para o cluster PolarDB sem alterações de configuração.

    Atualize uma instância RDS para um cluster PolarDB da mesma versão ou de uma versão superior. Por exemplo:

    • Instância ApsaraDB RDS for MySQL 5.6: atualize para um cluster PolarDB for MySQL 5.6, 5.7, 8.0.1 ou 8.0.2.

    • Instância ApsaraDB RDS for MySQL 5.7: atualize para um cluster PolarDB for MySQL 5.7, 8.0.1 ou 8.0.2.

    • Instância ApsaraDB RDS for MySQL 8.0: atualize para um cluster PolarDB for MySQL 8.0.1 ou 8.0.2.

      Nota

      • O PolarDB for MySQL 8.0.1 é totalmente compatível com o MySQL Community Edition 8.0.13 e versões anteriores. A versão 8.0.2 é totalmente compatível com o MySQL Community Edition 8.0.18 e versões anteriores.

      • Os recursos do PolarDB for MySQL 8.0.1 e 8.0.2 diferem entre si. Consulte a Comparação de recursos das versões do kernel.

    Métodos de migração

    Dois métodos de migração estão disponíveis: migração física (replicação física) e migração lógica (sincronização de dados DTS). O sistema seleciona o método com base na versão MySQL, na edição e no tipo de armazenamento da instância RDS. Não é possível alterar o método.

    Item

    Migração física (replicação física)

    Migração lógica (sincronização de dados DTS)

    Instância aplicável

    Instâncias da High-availability Edition do ApsaraDB RDS for MySQL 5.6 e 5.7 que utilizam local SSDs. Essas instâncias podem ser atualizadas para clusters PolarDB for MySQL da mesma versão.

    Nota

    Requisitos de versão secundária:

    • Para a High-availability Edition do ApsaraDB RDS for MySQL 5.6, a versão secundária deve ser 20190815 ou posterior.

    • Para a High-availability Edition do ApsaraDB RDS for MySQL 5.7, a versão secundária deve ser 20200331 ou posterior.

    Exceto pelo método de migração física (replicação física), outros tipos de instâncias RDS for MySQL podem ser atualizados para clusters PolarDB for MySQL da mesma versão ou de uma versão diferente.

    Nota

    Sem restrições de versão secundária.

    Como funciona

    Copia todos os dados da instância RDS e mantém a sincronização incremental para o cluster PolarDB.

    Importante

    Durante a sincronização incremental, quaisquer tabelas não InnoDB criadas são convertidas em tabelas InnoDB.

    Utiliza o DTS para criar uma tarefa que executa a sincronização completa de dados e esquemas da instância RDS para o cluster PolarDB, seguida pela sincronização incremental.

    Nota

    • Durante a inicialização completa dos dados, operações INSERT simultâneas causam fragmentação de tabela no cluster PolarDB. Portanto, após a conclusão da inicialização completa, o tablespace do cluster PolarDB será maior que o da instância RDS.

    • O uso elevado de memória pode ocorrer durante a fase de inicialização completa dos dados. Isso acontece porque o pool de buffer de memória do mecanismo InnoDB, innodb_buffer_pool, armazena dados em cache ativamente para acelerar operações de leitura e gravação, aumentando o uso geral de memória. Após a conclusão do upgrade com um clique, ajuste o tamanho do buffer de memória, innodb_buffer_pool_size, no console para reduzir essa parte do uso de memória.

    DTS necessário

    Não.

    Sim.

    Versão do MySQL migrada

    Suporta apenas migração entre a mesma versão.

    Suporta migração para a mesma versão ou para uma versão superior.

    Limite de duração do upgrade

    Conclua a migração em até 30 dias. Após esse período, o recurso de migração é desativado.

    Conclua a migração em até 30 dias. Após esse período, o recurso de migração é desativado.

    Migração entre regiões

    Não suportada.

    Não suportada.

    Sincronização incremental

    Suportada.

    Suportada.

    Migração de novos bancos de dados

    Suportada.

    Não suportada.

    Nota

    Para sincronizar novos bancos de dados, acesse o console do DTS e modifique os objetos de sincronização. Adicione os novos bancos de dados tanto nas tarefas de sincronização direta quanto nas reversas.

    Migração de esquema

    Suportada.

    Apenas os esquemas de bancos de dados, tabelas, visualizações, procedimentos armazenados e funções podem ser migrados.

    Benefícios

    • Alternância com endpoints: Mantenha o endpoint original do banco de dados, permitindo que suas aplicações alternem para o cluster PolarDB sem modificar nenhuma configuração de conexão.

    • O processo de upgrade com um clique garante zero perda de dados.

    • Suporta migração incremental.

    • Suporta migração a quente online. Seu serviço sofre apenas uma breve interrupção única, inferior a 10 minutos, durante a operação de alternância.

    • Suporta reversão da migração. Reverta a migração em até 10 minutos se ela falhar ou se seus requisitos de negócios mudarem.

    Impacto nas instâncias RDS

    O upgrade com um clique restringe algumas operações na instância RDS e pode causar uma breve interrupção ou aumento de carga.

    • Não modifique parâmetros da instância durante o processo de upgrade com um clique.

    • Durante o processo de upgrade com um clique, não cancele a assinatura, libere ou altere a zona da instância RDS.

    • Durante a operação de alternância, se você escolher Switchover with Endpoints, seu negócio pode ser interrompido por 1 a 5 minutos. Se escolher Switchover without Endpoints, atualize prontamente as configurações de conexão da sua aplicação para conectar-se ao cluster PolarDB.

    • De acordo com o método de migração, ao executar um upgrade com um clique usando a migração lógica (sincronização de dados DTS), os seguintes impactos se aplicam:

      • Se existirem triggers na instância RDS, exclua-as antes de iniciar. Caso contrário, a migração será interrompida.

      • Durante a inicialização completa dos dados, não execute operações DDL que alterem esquemas de banco de dados ou tabelas. Isso pode causar falha na tarefa de sincronização de dados.

      • A inicialização completa dos dados consome recursos de leitura e gravação, como CPU e IOPS, tanto na instância RDS quanto no cluster PolarDB. Isso pode aumentar a carga na instância RDS.

    Notas de uso

    Pré-requisitos

    Sua instância RDS deve atender às seguintes condições:

    • Especificações da instância:

      Versão do MySQL

      Basic Edition

      High-availability Edition

      Cluster Edition

      5.6

      -

      local SSD

      -

      5.7

      cloud disk

      local SSD, cloud disk

      cloud disk

      8.0

      cloud disk

      local SSD, cloud disk

      cloud disk

    • O tipo de mecanismo de armazenamento para a tabela de dados deve ser InnoDB ou X-Engine.

    • Se sua instância não atender aos requisitos para migração física (replicação física), o sistema selecionará automaticamente a migração lógica (sincronização de dados DTS) para o upgrade. Nesse caso, para evitar falhas no upgrade com um clique, a instância RDS também deve atender às seguintes condições:

      • A instância RDS não deve fazer parte de nenhuma tarefa existente de sincronização bidirecional do DTS. Prosseguir com o upgrade nesse caso pode causar inconsistência de dados.

      • Se existirem triggers na instância RDS, exclua-as antes de iniciar. Caso contrário, a migração será interrompida.

      • O log binário é ativado por padrão na instância RDS. Certifique-se de que o parâmetro binlog_row_image esteja definido como full. Caso contrário, um erro será relatado durante a pré-verificação e a tarefa de sincronização de dados não poderá ser iniciada.

      • O DTS exige que os logs binários da instância RDS sejam retidos por pelo menos sete dias. Caso contrário, o DTS pode falhar ao obter os logs binários, causando falha na tarefa e, em casos extremos, levando à inconsistência ou perda de dados. Problemas causados pela definição de um período de retenção de log binário menor que o requisito do DTS não são cobertos pelo Acordo de Nível de Serviço (SLA) do DTS.

    • Se sua instância não atender aos requisitos para migração física (replicação física), mas você quiser usar este método para realizar um upgrade com um clique, execute as seguintes operações para adequar sua instância RDS aos requisitos de migração física (replicação física) e, em seguida, realize o upgrade com um clique:

      • Para a High-availability Edition do ApsaraDB RDS for MySQL 5.6, a versão secundária deve ser 20190815 ou posterior.

      • Para a High-availability Edition do ApsaraDB RDS for MySQL 5.7, a versão secundária deve ser 20200331 ou posterior.

      Nota

      • Acesse a página RDS console > Instance Details > Basic Information. Na seção Configurations, visualize as minor version information da instância RDS. Se a versão for inferior à especificada acima, atualize a versão secundária para a versão mais recente.

      • Para a migração física (replicação física), defina o período de retenção para logs binários como pelo menos 24 horas.

    Limitações

    Se sua instância não atender aos requisitos para migração física (replicação física), o sistema seleciona automaticamente a migração lógica (sincronização de dados DTS) para realizar o upgrade. Este método de migração possui as seguintes limitações de uso:

    • Não grave dados no banco de dados de destino exceto através do DTS enquanto a sincronização estiver em execução. Caso contrário, pode ocorrer inconsistência de dados entre os bancos de dados de origem e destino. Por exemplo, se você usar o DMS para executar operações DDL online enquanto outros dados são gravados no banco de dados de destino, pode ocorrer perda de dados.

    • O DTS desativa restrições de chave estrangeira por padrão ao sincronizar para um banco de dados de destino. Portanto, operações em cascata e exclusões no banco de dados de origem não são sincronizadas para o banco de dados de destino.

    • Instruções SQL suportadas para sincronização incremental:

      Tipo de operação

      Instrução SQL

      DML

      INSERT, UPDATE, DELETE

      DDL

      • ALTER TABLE, ALTER VIEW

      • CREATE FUNCTION, CREATE INDEX, CREATE PROCEDURE, CREATE TABLE, CREATE VIEW

      • DROP INDEX, DROP TABLE

      • RENAME TABLE

      • TRUNCATE TABLE

    Considerações

    Fase da migração

    Descrição

    Antes da migração

    Durante a migração

    • Ao criar o cluster PolarDB, a sincronização completa dos dados é iniciada. A duração depende do volume de dados, e o status do cluster permanece como Creating durante esse processo.

    • Ao executar uma (Opcional) alternância com endpoints, apenas os endpoints de conexão que existem tanto na instância RDS quanto no cluster PolarDB podem ser alternados. Crie os endpoints de conexão correspondentes no cluster antes da alternância. Caso contrário, a alternância não ocorrerá.

    • O status de criptografia SSL dos endpoints deve corresponder:

    • Para a migração lógica (sincronização de dados DTS), não libere manualmente a tarefa de sincronização de dados do DTS.

    Faturamento

    Taxas de migração

    Migração lógica (sincronização de dados DTS)

    Para o método de migração lógica (sincronização de dados DTS), você é cobrado pela tarefa de sincronização de dados do DTS e pelo cluster PolarDB de destino.

    • Tarefa de sincronização de dados do DTS:

      Durante o upgrade, o sistema cria automaticamente uma tarefa de sincronização de dados do DTS entre a instância RDS e o cluster PolarDB. Visão geral do faturamento do DTS.

    • Cluster PolarDB de destino:

      • Se o método de faturamento for pagamento conforme o uso, o cluster não será faturado durante o processo de upgrade. O faturamento padrão de pagamento conforme o uso começa após uma das seguintes operações:

        • A migração é concluída (incluindo a operação Complete Migration).

          Nota

          • A migração é considerada concluída quando o link de sincronização entre a instância RDS e o cluster PolarDB é encerrado.

          • A migração deve ser concluída dentro de 30 dias. Após esse período, o recurso de migração é desativado, e tanto a instância RDS quanto o cluster PolarDB retornam ao status de leitura/gravação, rompendo o link de replicação.

        • A migração é interrompida (incluindo a operação Abandon Migration para falhas na pré-verificação e a operação Cancel Migration).

          Neste ponto, o cluster PolarDB de destino já foi criado, mas o processo de upgrade foi interrompido. Se você não precisar mais do cluster PolarDB de destino, libere-o prontamente.

      • Se o método de faturamento for Serverless, o faturamento começa assim que o status do cluster mudar para Running.

      • Se o método de faturamento for assinatura, você deve pagar a taxa correspondente ao criar o cluster.

    Migração física (replicação física)

    Para o método de migração física (replicação física), não há taxas extras para o processo de upgrade. Você paga apenas pelo cluster PolarDB de destino.

    • Se o método de faturamento for pagamento conforme o uso, o cluster não será faturado durante o processo de upgrade. O faturamento padrão de pagamento conforme o uso começa após uma das seguintes operações:

      • A migração é concluída (incluindo a operação Complete Migration).

        Nota

        • A migração é considerada concluída quando o link de sincronização entre a instância RDS e o cluster PolarDB é encerrado.

        • A migração deve ser concluída dentro de 30 dias. Após esse período, o recurso de migração é desativado, e tanto a instância RDS quanto o cluster PolarDB retornam ao status de leitura/gravação, rompendo o link de replicação.

      • A migração é interrompida (incluindo a operação Abandon Migration para falhas na pré-verificação e a operação Cancel Migration).

        Neste ponto, o cluster PolarDB de destino já foi criado, mas o processo de upgrade foi interrompido. Se você não precisar mais do cluster PolarDB de destino, libere-o prontamente.

    • Se o método de faturamento for Serverless, o faturamento começa assim que o status do cluster mudar para Running.

    • Se o método de faturamento for assinatura, você deve pagar a taxa correspondente ao criar o cluster.

    Primeiros passos

    1. Avaliação da migração

    O PolarDB fornece um recurso de avaliação de migração para pré-verificar o status da instância, dependências de tarefas e atributos da instância antes de você começar. Isso ajuda a identificar e resolver problemas potenciais antecipadamente.

    2. Etapas do upgrade

    Operações no console

    Esta seção descreve o processo de upgrade com um clique. Etapas do upgrade.

    1. (Opcional) Verifique a lista de permissões de endereços IP

      Se sua instância RDS possuir instâncias somente leitura e as listas de permissões de endereços IP delas forem diferentes da lista da instância primária, mescle as listas das instâncias somente leitura na lista da instância primária. Isso garante que as listas de permissões sejam sincronizadas automaticamente para o cluster PolarDB.

      Nota

      A lista de permissões de endereços IP de um cluster PolarDB aplica-se a todo o cluster. Não é possível configurar listas de permissões separadas para nós individuais. Portanto, após a conclusão da migração, revise a lista de permissões de endereços IP e as permissões da conta do banco de dados do cluster PolarDB.

    2. Crie um cluster PolarDB

      Acesse a página de compra de cluster PolarDB. Defina o método de criação como Migrate from RDS e especifique a versão e a instância da instância RDS de origem para comprar um cluster PolarDB. Após a conclusão da compra, o sistema realiza a inicialização, uma pré-verificação e a sincronização completa dos dados. Durante esse processo, o status do cluster é Creating. Aguarde a conclusão.

      Nota

      Durante a migração lógica (sincronização de dados DTS), pode ocorrer um erro como Precheck Failed. Resolva o erro com base na Error Message. Após resolver o erro, clique em Continue para retomar o processo de upgrade com um clique. Se a resolução do erro afetar seus serviços online, clique em Abandon Migration para interromper o processo de upgrade.

    3. (Opcional) Adicione endpoints ausentes

      O recurso de alternância com endpoints mantém os endpoints originais do banco de dados. Isso permite que suas aplicações alternem para o cluster PolarDB sem alterar nenhuma configuração de conexão. No entanto, só é possível alternar endpoints que existam tanto na instância RDS quanto no cluster PolarDB.

      1. Conforme necessário, adicione os endpoints de banco de dados exigidos no cluster PolarDB.

      2. Verifique o status de criptografia SSL dos endpoints de banco de dados. O status SSL para os endpoints da instância RDS e do cluster PolarDB deve ser o mesmo.

    4. Alternância

      Quando a Replication Latency do cluster PolarDB for inferior a 60 segundos, alterne seus serviços. Clique em Switch Over. Esta ação troca o status de leitura/gravação da instância RDS e do cluster PolarDB. A instância RDS torna-se somente leitura, e o cluster PolarDB torna-se leitura/gravação. A direção da replicação de dados também é invertida. Novos dados do cluster PolarDB são sincronizados para a instância RDS.

      Importante

    5. (Opcional) Alterne a tarefa DTS da instância de origem

      Se a instância RDS tiver um link associado ao Data Transmission Service (DTS), diferente daquele usado para migração lógica neste processo de upgrade, utilize este recurso. Ele permite alterar a instância de origem ou destino da tarefa de sincronização ou migração do DTS para alternar suavemente os serviços associados.

    6. Conclua a migração

      Depois que seus dados forem migrados e seus serviços estiverem executando de forma estável no cluster PolarDB, encerre o processo de upgrade. Se a sincronização de dados não for mais necessária, clique em Complete Migration.

    7. (Opcional) Cancele a assinatura ou libere a instância RDS

      Se seus serviços estiverem executando de forma estável no cluster PolarDB e a instância RDS não for mais necessária, cancele a assinatura ou libere a instância RDS.

    Operações de API

    Esta seção descreve o processo de upgrade com um clique. Etapas do upgrade.

    1. (Opcional) Verifique a lista de permissões de endereços IP

      Se sua instância RDS possuir instâncias somente leitura e as listas de permissões de endereços IP delas forem diferentes da lista da instância primária, mescle as listas das instâncias somente leitura na lista da instância primária. Isso garante que as listas de permissões sejam sincronizadas automaticamente para o cluster PolarDB.

      Nota

      A lista de permissões de endereços IP de um cluster PolarDB aplica-se a todo o cluster. Não é possível configurar listas de permissões separadas para nós individuais. Portanto, após a conclusão da migração, revise a lista de permissões de endereços IP e as permissões da conta do banco de dados do cluster PolarDB.

    2. CreateDBCluster - Criar um cluster PolarDB

      Ao chamar a API de criação de cluster, defina o parâmetro SourceResourceId para a região onde a instância RDS de origem está localizada, o parâmetro CreationOption como MigrationFromRDS e o parâmetro SourceResourceId como o ID da instância RDS de origem. Após a conclusão da chamada, o sistema executa operações como inicialização, pré-verificação e sincronização completa dos dados. Durante esse processo, o status do cluster é Precheck Failed. Aguarde a conclusão.

    3. Consulte o status da migração do cluster PolarDB

      Quando o parâmetro MigrationStatus retornado for RDS2PolarDB_SYNCING, indica que o sistema concluiu a sincronização completa dos dados e agora está realizando a sincronização incremental.

      Nota

      Durante a migração lógica (sincronização de dados DTS), pode ocorrer um erro como Error Message. Nesse caso, o parâmetro MigrationStatus será PRE_CHECK_FAIL. Resolva o erro com base na Error Message

    4. ModifyDBClusterMigration - Alternar uma tarefa de migração

      Quando o parâmetro DelayedSeconds retornado por DescribeDBClusterMigration for inferior a 60 segundos, execute a alternância de negócios. Troque o status de leitura/gravação da instância RDS e do cluster PolarDB (defina a instância RDS como somente leitura e o cluster PolarDB como leitura/gravação) e altere a direção da replicação de dados (sincronize novos dados do cluster PolarDB para a instância RDS).

      Importante

      • Se você usar a alternância com endpoints, leia atentamente as notas sobre alternância com endpoints. Observe que seus serviços podem ser interrompidos por 1 a 5 minutos durante o processo de alternância.

      • Após a conclusão da alternância de migração, se encontrar inconsistências de dados ou outros problemas, chame ModifyDBClusterMigration para reverter a tarefa de migração e restaurar prontamente o estado anterior ao upgrade. Posteriormente, você também pode chamar CloseDBClusterMigration para cancelar a migração e restaurar o estado anterior à alternância.

    5. (Opcional) ModifyDtsJobEndpoint - Modificar a instância de banco de dados de origem ou destino de um trabalho DTS

      Se sua instância RDS tiver um link DTS associado (diferente de um link de sincronização de dados DTS para migração lógica em um processo de upgrade com um clique), modifique (substitua) a instância de banco de dados de origem ou destino da tarefa de sincronização ou migração do DTS para alternar suavemente os serviços associados.

    6. CloseDBClusterMigration - Concluir migração

      Após a conclusão da migração de dados de negócios e com seus serviços executando de forma estável no cluster PolarDB, encerre o processo de upgrade com um clique se não precisar mais da sincronização de dados.

    7. (Opcional) Cancele a assinatura ou libere a instância RDS

      Se seus serviços estiverem executando de forma estável no cluster PolarDB e a instância RDS não for mais necessária, cancele a assinatura ou libere a instância RDS.

    3. Ajuste a política de backup

    O RDS e o PolarDB possuem políticas de backup diferentes. Após a conclusão da migração, modifique a política de backup no console conforme necessário.

    Informações relacionadas

    Descrição da política de backup

    As políticas de backup do RDS e do PolarDB são diferentes. As diferenças são as seguintes:

    • Ciclo regular de backup e Hora de início do backup: Estas configurações são iguais. Por padrão, o PolarDB utiliza o mesmo ciclo regular de backup e hora de início que a instância RDS.

    • Período de retenção de backup: O mapeamento é o seguinte:

      • Se o período de retenção de backup do RDS for de 14 dias ou menos, o período de retenção de backup Nível 1 do PolarDB será igual ao período de retenção de backup do RDS.

      • Se o período de retenção de backup do RDS for superior a 14 dias, mas não exceder 30 dias, o período de retenção de backup Nível 1 do PolarDB é fixado em 14 dias. O backup Nível 2 também é ativado, e o período de retenção de backup Nível 2 do PolarDB na mesma região é fixado em 30 dias. Se o período de retenção de backup do RDS for superior a 30 dias, o PolarDB ativa o backup Nível 2, e o período de retenção de backup Nível 2 na mesma região será igual ao período de retenção de backup do RDS.

      • Se os backups do RDS estiverem configurados para retenção de longo prazo, o período de retenção de backup Nível 1 do PolarDB é fixado em 14 dias. O backup Nível 2 também é ativado para retenção de longo prazo.

    • Se o backup de alta frequência estiver ativado para a instância RDS, ele também será ativado para o cluster PolarDB por padrão. Backup de alta frequência: O mapeamento de frequência é o seguinte:

      • Se o intervalo de backup de alta frequência do RDS for de 120 minutos ou menos, o intervalo de backup de alta frequência do PolarDB é fixado em 120 minutos.

      • Se o intervalo de backup de alta frequência do RDS for superior a 120 minutos, mas não exceder 180 minutos, o intervalo de backup de alta frequência do PolarDB é fixado em 180 minutos.

      • Para qualquer outro intervalo de backup do RDS, o intervalo de backup de alta frequência do PolarDB é fixado em 240 minutos.

    Alternância com endpoints

    Durante o upgrade, selecione o recurso de alternância com endpoints para trocar automaticamente os endpoints de conexão entre a instância RDS e o cluster PolarDB. Isso permite que suas aplicações se conectem automaticamente ao cluster PolarDB sem alterações de configuração.

    Importante

    Antes de alternar os endpoints, confirme o mapeamento dos endpoints de conexão entre a instância RDS e o cluster PolarDB. Isso evita interrupções nos negócios.

    Diagrama de alternância de endpoints de conexão

    O diagrama a seguir mostra o mapeamento padrão para a alternância de endpoints de conexão entre uma instância RDS e um cluster PolarDB. Ajuste esse mapeamento no console durante o processo de alternância.

    image
    Nota

    O endpoint somente leitura de uma instância RDS inclui o endpoint somente leitura no proxy de banco de dados e o endpoint de conexão da instância somente leitura.

    Notas

    • O recurso de alternância com endpoints não suporta alternância de endereços IPv6.

    • O recurso de alternância com endpoints troca apenas os nomes de domínio dos endpoints de conexão da instância RDS e do cluster PolarDB. Configurações como switches virtuais (vSwitches) e endereços IP virtuais (VIPs) não são trocadas.

    • Apenas endpoints de conexão que existem tanto na instância RDS quanto no cluster PolarDB podem ser trocados. Por padrão, um cluster PolarDB cria apenas um endpoint primário privado e um endpoint de cluster privado. Se a instância RDS tiver mais de dois endpoints de conexão, crie os endpoints de conexão correspondentes no cluster PolarDB antes da alternância. Caso contrário, os endpoints não serão trocados.

    • Ao usar o recurso de alternância com endpoints, o endpoint de conexão primário da instância RDS pode ser trocado pelo endpoint primário ou endpoint de cluster padrão do cluster PolarDB. O endpoint de proxy de banco de dados da instância RDS pode ser trocado pelo endpoint de cluster padrão e endpoints personalizados do cluster PolarDB. Você também pode optar por não trocá-los ou trocar vários grupos. Como um cluster PolarDB pode ter até sete endpoints de cluster, é possível trocar no máximo sete endpoints de proxy de banco de dados da instância RDS.

    • Atualmente, a alternância não é suportada para o endpoint somente leitura do cluster e o endpoint de conexão direta do nó de instâncias da Cluster Edition do RDS.

    • Antes de usar o recurso de alternância com endpoints para trocar endpoints privados, certifique-se de que a instância RDS e o cluster PolarDB estejam na mesma VPC. Caso contrário, seus serviços existentes não poderão se conectar após a alternância.

    • Após a conclusão da sincronização incremental, o status do cluster PolarDB muda para Running. Antes de alternar os endpoints, execute operações como configurar parâmetros, adicionar nós somente leitura e adicionar endpoints.

    • Após a troca dos nomes de domínio dos endpoints de conexão, se precisar fazer login no cluster PolarDB usando o Data Management (DMS), certifique-se de ter configurado o ID do cluster ou string de conexão corretos.

    • Após a troca dos nomes de domínio dos endpoints de conexão, podem ocorrer problemas de cache de resolução DNS. Antes que o cache expire, talvez não seja possível conectar-se ao cluster PolarDB, ou o cluster PolarDB pode suportar apenas operações de leitura, mas não de gravação. Limpe o cache DNS no seu servidor.

    Perguntas frequentes

    Por que o uso de memória de um cluster **PolarDB** fica alto durante o processo de upgrade com um clique?

    Durante a inicialização completa dos dados, o mecanismo InnoDB armazena dados em cache no pool de buffer de memória innodb_buffer_pool para acelerar as operações de leitura e gravação. Esse processo faz com que o uso geral de memória aumente.

    Após a conclusão do upgrade com um clique, ajuste o parâmetro innodb_buffer_pool_size no console para reduzir o uso de memória do pool de buffer.