PolarDB:Perguntas frequentes

O que fazer se um item de verificação da avaliação de migração falhar?

A tabela a seguir lista cada item de verificação e a ação necessária.

-- List all triggers
SHOW TRIGGERS;
-- Delete a specific trigger
DROP TRIGGER trigger_name;

SELECT t1.table_schema, t1.table_name
FROM information_schema.TABLES t1 LEFT OUTER
    JOIN information_schema.TABLE_CONSTRAINTS t2
    ON t1.table_schema = t2.TABLE_SCHEMA AND t1.table_name = t2.TABLE_NAME AND t2.CONSTRAINT_NAME
    IN ("PRIMARY")
WHERE t2.table_name IS NULL AND t1.table_type = "BASE TABLE" AND t1.TABLE_SCHEMA NOT IN ("information_schema", "performance_schema", "mysql", "sys")

É necessário adquirir um cluster PolarDB antes da atualização?

Não. O processo de atualização cria automaticamente um cluster do PolarDB for MySQL com os mesmos dados da instância RDS de origem.

Os nós do cluster PolarDB precisam corresponder ao tipo da instância RDS de origem?

Não necessariamente. Selecione as especificações de nó adequadas à sua carga de trabalho. Utilize especificações iguais ou superiores ao tipo da instância RDS de origem como base.

A migração afeta a instância RDS de origem?

Não. A operação normal da instância RDS de origem permanece inalterada.

A migração suave consome recursos da instância RDS de origem?

A migração suave não afeta a disponibilidade da instância RDS de origem. No entanto, a migração de dados envolve operações de consulta que consomem parte da capacidade de consulta da instância RDS de origem.

Qual é o tempo de inatividade causado por uma migração suave?

Uma migração suave garante que nenhum dado seja perdido. O tempo de inatividade é inferior a 10 minutos. Durante essa janela, sua aplicação é pausada para evitar novas gravações, mas o banco de dados em si não é interrompido. Se necessário, reverta a migração.

O que acontece se eu cancelar a migração?

• O vínculo de sincronização entre os clusters de origem e de destino é desconectado e eles deixam de estar associados.

• O cluster de destino passa a operar em modo de leitura e gravação e não é liberado automaticamente. Libere-o imediatamente se não for mais necessário para evitar cobranças indevidas.

• Ao cancelar manualmente a migração, escolha se deseja desativar o log binário do cluster. O log binário não é desativado se a migração for cancelada automaticamente.

Sobre a desativação do log binário:

Desativar o log binário melhora ligeiramente o desempenho de gravação. Os arquivos de log binário existentes são retidos após a desativação. Antes de desativar, reduza o período de retenção dos arquivos de log binário e aguarde a exclusão automática desses arquivos. Após desativar o log binário, o cluster reinicia automaticamente. A reinicialização é concluída em até 5 minutos, período em que ocorre uma desconexão transitória de cerca de 40 segundos (a duração exata depende do volume de dados e do número de tabelas). Execute essa operação fora dos horários de pico e certifique-se de que sua aplicação possua um mecanismo de reconexão.

Preciso atualizar as strings de conexão na minha aplicação após mudar para o PolarDB?

Não, se você selecionar Switch with Endpoints (Connection Changes Not Required) durante o switchover. O sistema troca automaticamente os endpoints do RDS e do PolarDB, permitindo que sua aplicação se conecte ao PolarDB sem alterações de configuração.

Selecionei "Switch with Endpoints (Connection Changes Not Required)", mas o cluster PolarDB ainda usa um novo endpoint. Por quê?

Os endpoints só são trocados quando existe um endpoint correspondente tanto na instância RDS de origem quanto no cluster PolarDB de destino. Por padrão, apenas o endpoint primário na rede privada é alternado.

Para alternar outros endpoints, crie os endpoints correspondentes no cluster de destino antes do switchover. Consulte Gerenciar endereços de conexão e Definir endereços de conexão.

Os endpoints das instâncias RDS somente leitura também podem ser alternados?

Sim. Ao selecionar Switch with Endpoints (Connection Changes Not Required), o endpoint de uma instância RDS somente leitura será alternado se o cluster PolarDB de destino possuir um endpoint de cluster ou endpoint personalizado correspondente.

Após o switchover, por que não consigo me conectar ao banco de dados PolarDB ou a conexão está somente leitura?

Isso provavelmente é causado pelo cache DNS local no seu servidor. Durante o tempo de vida (TTL) do cache, sua aplicação pode falhar ao se conectar ou estabelecer uma conexão somente leitura. Atualize o cache DNS no seu servidor para resolver esse problema.

Após a atualização, preciso recriar contas e senhas da instância RDS de origem?

Não. Após a atualização, o cluster PolarDB herda automaticamente contas, senhas, bancos de dados, listas de permissões de IP e parâmetros necessários da instância RDS de origem.

Posso modificar permissões de conta durante a migração e atualização?

Não. Não é possível modificar permissões de conta durante uma migração ativa. As permissões da conta privilegiada no cluster de destino são sincronizadas a partir da instância de origem. Se a conta privilegiada estiver sem as permissões padrão após a atualização, redefina-as na página Account Management no console.

A instância RDS de origem tem SSL ativado. Ainda posso usar a atualização com um clique?

Sim. Tanto a Migração Física quanto a Migração Lógica oferecem suporte a instâncias RDS com Secure Sockets Layer (SSL) ativado.

A instância RDS de origem tem TDE (Transparent Data Encryption) ativado. Ainda posso usar a atualização com um clique?

Sim. Tanto a Migração Física quanto a Migração Lógica oferecem suporte a instâncias RDS com Transparent Data Encryption (TDE) ativado.

A atualização com um clique suporta atualizações entre versões?

Sim. A Migração Lógica (sincronização de dados via DTS) suporta atualizações entre versões, como a atualização do RDS MySQL 5.6 para o PolarDB for MySQL 8.0.

Tarefas do DTS e compatibilidade

Erros e solução de problemas

Comparação entre atualização e clonagem