Como solucionar uma tarefa do AWS DMS que está falhando com a mensagem de erro “ERRO: cancelamento da declaração devido ao tempo limite da declaração”?

Breve descrição

Se o banco de dados PostgreSQL for a origem da sua tarefa de migração, o AWS DMS obterá dados da tabela durante a fase de carregamento completo. Em seguida, o AWS DMS lê os logs de gravação antecipada (WALs) que são mantidos pelo slot de replicação durante a fase de captura de dados de alteração (CDC).

Se o banco de dados PostgreSQL for o destino, o AWS DMS obterá os dados da origem e criará arquivos CSV na instância de replicação. Em seguida, o AWS DMS executa um comando COPY para inserir esses registros no destino durante a fase de carregamento completo.

Mas, durante a fase de CDC, o AWS DMS executa as declarações DML exatas dos logs WAL de origem no modo de aplicação transacional. Para o modo de aplicação em lote, o AWS DMS também cria arquivos CSV durante a fase de CDC. Em seguida, ele executa um comando COPY para inserir as alterações líquidas no destino.

Quando o AWS DMS tenta obter dados da fonte ou colocá-los no destino, ele usa a configuração de tempo limite padrão de 60 segundos. Se a origem ou o destino estiverem muito carregados ou houver bloqueios nas tabelas, o AWS DMS não poderá terminar de executar esses comandos em 60 segundos. Portanto, a tarefa falha com um erro que diz “cancelamento da declaração devido ao tempo limite da declaração”, e você vê uma dessas entradas no log:

Mensagens:

“]E: RetCode: SQL_ERROR SqlState: 57014 NativeError: 1 Message: ERRO: cancelamento da declaração devido ao tempo limite da declaração; erro ao executar a consulta [1022502] (ar_odbc_stmt.c:2738)”

“]E: test_decoding_create_replication_slot(...) - Unable to create slot 'lrcyli7hfxcwkair_00016402_8917165c_29f0_4070_97dd_26e78336e01b' (on execute(...) phase) [1022506] (postgres_test_decoding.c:392))”

Para solucionar esses erros, siga estas etapas:

• Identifique a causa dos longos tempos de execução dos comandos.
• Aumente o valor do tempo limite e verifique o valor do tempo limite de criação do slot.
• Solucione problemas de criação de slots.

Resolução

Identifique a causa dos longos tempos de execução dos comandos

Para encontrar o comando que falhou a execução durante o período de tempo limite, analise o log de tarefas do AWS DMS e a seção de estatísticas da tabela da tarefa. Você também pode encontrar essas informações no arquivo de log de erros do PostgreSQL se o parâmetro log_min_error_statement estiver definido como ERROR ou com uma severidade menor. Depois de identificar o comando que falhou, você pode encontrar os nomes das tabelas que falharam. Veja este exemplo de mensagem de erro do log de erros do PostgreSQL:

ERROR: canceling statement due to statement timeout
STATEMENT: <The statement executed>"

Para encontrar bloqueios nas tabelas associadas, execute este comando na origem ou no destino (dependendo de onde o erro está aparecendo):

SELECT blocked_locks.pid AS blocked_pid,
 blocked_activity.usename AS blocked_user,
 blocking_locks.pid AS blocking_pid,
         blocking_activity.usename AS blocking_user,
         blocked_activity.query    AS blocked_statement,
         blocking_activity.query   AS current_statement_in_blocking_process
   FROM  pg_catalog.pg_locks         blocked_locks
    JOIN pg_catalog.pg_stat_activity blocked_activity  ON blocked_activity.pid = blocked_locks.pid
    JOIN pg_catalog.pg_locks         blocking_locks
        ON blocking_locks.locktype = blocked_locks.locktype
        AND blocking_locks.DATABASE IS NOT DISTINCT FROM blocked_locks.DATABASE
        AND blocking_locks.relation IS NOT DISTINCT FROM blocked_locks.relation
        AND blocking_locks.page IS NOT DISTINCT FROM blocked_locks.page
        AND blocking_locks.tuple IS NOT DISTINCT FROM blocked_locks.tuple
        AND blocking_locks.virtualxid IS NOT DISTINCT FROM blocked_locks.virtualxid
        AND blocking_locks.transactionid IS NOT DISTINCT FROM blocked_locks.transactionid
        AND blocking_locks.classid IS NOT DISTINCT FROM blocked_locks.classid
        AND blocking_locks.objid IS NOT DISTINCT FROM blocked_locks.objid
        AND blocking_locks.objsubid IS NOT DISTINCT FROM blocked_locks.objsubid
        AND blocking_locks.pid != blocked_locks.pid
    JOIN pg_catalog.pg_stat_activity blocking_activity ON blocking_activity.pid = blocking_locks.pid
   WHERE NOT blocked_locks.GRANTED;

Se você encontrar algum PID bloqueado, interrompa ou encerre o PID bloqueado executando este comando:

SELECT pg_terminate_backend(blocking_pid);

Como as linhas inativas, ou “tuplas”, podem aumentar o tempo de SELECT, verifique se há um grande número de linhas inativas nas tabelas de origem executando este comando:

select * from pg_stat_user_tables where relname= 'table_name';

Verifique se a tabela de destino com falha tem chaves primárias ou índices exclusivos. Se a tabela não tiver chaves primárias ou índices exclusivos, uma verificação completa da tabela será executada durante a execução de qualquer declaração UPDATE. Essa verificação da tabela pode levar bastante tempo.

Aumente o valor do tempo limite

O AWS DMS usa o atributo de conexão extra executeTimeout nos endpoints de origem e de destino. O valor padrão de executeTimeout é 60 segundos, então o AWS DMS atinge o tempo limite se uma consulta levar mais de 60 segundos para ser executada.

Se o erro aparecer em Source_Unload ou Source_Capture, defina o valor do tempo limite para executeTimeout na origem. Se o erro aparecer em Target_Load ou Target_Apply, defina o valor do tempo limite para executeTimeout no destino. Aumente a configuração do valor do tempo limite seguindo estas etapas:

1.    Abra o console do AWS DMS.

2.    Selecione Endpoints no painel de navegação.

3.    Selecione o endpoint do PostgreSQL.

4.    Selecione Ações e, em seguida, selecione Modificar.

5.    Expanda a seção Configurações específicas do endpoint.

6.    No campo de Atributos de conexão extras, insira este valor:

executeTimeout=3600;

7.    Selecione Salvar.

8.    No painel Endpoints, selecione o nome do endpoint do PostgreSQL.

9.    Na seção Conexões, o Status do endpoint muda de Em teste para Sucesso.

Você pode aumentar (em milissegundos) o parâmetro statement_timeout na instância de banco de dados PostgreSQL. O valor padrão é 0, o que desativa os tempos limite de qualquer consulta. Você também pode aumentar o parâmetro lock_timeout. O valor padrão é 0, o que desativa os tempos limite dos bloqueios.

Solucione problemas de criação de slots

Se o tempo limite ocorreu quando você criou o slot de replicação no banco de dados PostgreSQL, você verá entradas de log semelhantes às seguintes:

Mensagens

“]E: test_decoding_create_replication_slot(...) - Unable to create slot 'lrcyli7hfxcwkair_00016402_8917165c_29f0_4070_97dd_26e78336e01b’ (on execute(...) phase) [1022506] (postgres_test_decoding.c:392)”

Você pode aumentar esse tempo limite configurando o parâmetro TransactionConsistencyTimeout na seção Configurações da tarefa. O valor padrão é 600 segundos.

O PostgreSQL não pode criar o slot de replicação se houver algum bloqueio ativo nas tabelas de usuários do banco de dados. Verifique se há bloqueios executando este comando:

select * from pg_locks;

Em seguida, para testar se o erro foi resolvido, execute este comando para criar manualmente o slot de replicação no banco de dados PostgreSQL de origem:

select  xlog_position FROM pg_create_logical_replication_slot('<Slot name as per
    the task log>', 'test_decoding');

Se o comando ainda não conseguir criar o slot, talvez você precise trabalhar com um administrador de banco de dados (DBA) de PostgreSQL para identificar o gargalo e configurar seu banco de dados. Se o comando for bem-sucedido, exclua o slot que você acabou de criar como teste:

select pg_drop_replication_slot(‘<slot name>');

Por fim, reinicie sua tarefa de migração.

---

Informações relacionadas

Documentação do PostgreSQL para padrões de conexão do cliente

Atributos de conexão extras ao usar o PostgreSQL como destino para o AWS DMS

Atributos de conexão extras ao usar o PostgreSQL como fonte do DMS

Como usar um banco de dados PostgreSQL como fonte do AWS DMS