Salta al contenuto

Perché la mia attività AWS DMS CDC non è riuscita generando il messaggio "Error 1236" quando ho utilizzato MySQL come origine?

9 minuti di lettura
0

Ho usato AWS Database Migration Service (AWS DMS) per eseguire la migrazione dei miei dati da un motore di database MySQL di origine a un motore di destinazione. Tuttavia, l'attività di acquisizione dei dati di modifica (CDC) non è riuscita generando il messaggio "Error 1236".

Breve descrizione

Con AWS DMS, puoi eseguire migrazioni una tantum e replicare le modifiche in corso per mantenere sincronizzate origini e destinazioni. Per leggere le modifiche in corso dal database di origine, AWS DMS utilizza azioni API specifiche del motore per leggere i log delle transazioni del motore di origine. Quando utilizzi MySQL come origine, AWS DMS legge le modifiche dai log binari basati su righe (binlog). Quindi esegue la migrazione delle modifiche alla destinazione.

Se sono presenti problemi nei log binari, ricevi il messaggio "Error 1236". Assicurati di configurare correttamente tutti i parametri di registrazione binaria per supportare l'attività CDC di AWS DMS quando utilizzi un database compatibile con MySQL self-managed o gestito da AWS.

Risoluzione

Per risolvere il problema che genera il messaggio "Error 1236", intraprendi le seguenti azioni in base al messaggio ricevuto.

"Could not find first log file name in binary log index file reading binlog"

Esempio di errore nei log delle attività:

[SOURCE_CAPTURE  ]I: Setting position in binlog 'mysql-bin-changelog.014448' at 119624570  (mysql_endpoint_capture.c:886)
[SOURCE_CAPTURE  ]I: Position was set in binlog 'mysql-bin-changelog.014448' at 119624570  (mysql_endpoint_capture.c:922)
[SOURCE_CAPTURE  ]E: Error 1236 (Could not find first log file name in binary log index file) reading binlog [1020493]
[TASK_MANAGER    ]I: Task - ABCDXXXXXXXXXXXXXX is in ERROR state, updating starting status to AR_NOT_APPLICABLE

L'errore precedente si verifica quando il database MySQL di origine ha rimosso il log binario utilizzato da AWS DMS per replicare nella destinazione le modifiche apportate ai dati. MySQL potrebbe rimuovere il log binario per i seguenti motivi:

  • Il periodo di conservazione del log binario è troppo breve.
  • L'attività AWS DMS è bloccata o arrestata a causa di un problema.

Per verificare se il log binario è disponibile, esegui questo comando per elencare tutti i file di log binari:

mysql> SHOW BINARY LOGS;

Quindi esegui questo comando per elencare il file di log binario corrente e la sua posizione:

mysql> SHOW MASTER STATUS;

Per ulteriori informazioni sui comandi precedenti, consulta SHOW BINARY LOGS statement (Istruzione SHOW BINARY LOGS) e SHOW MASTER STATUS statement (istruzione SHOW MASTER STATUS) sul sito web MySQL.

Per risolvere l'errore, controlla il periodo di conservazione del log binario nel database MySQL di origine. Se necessario, aumenta il periodo di conservazione. Riavvia l'attività AWS DMS per eseguire nuovamente la fase di caricamento completo.

Intraprendi le seguenti azioni in base al tipo di database.

Database MySQL self-managed

Per verificare il periodo di conservazione dei log binari per Amazon Elastic Compute Cloud (Amazon EC2) on-premises o Amazon Elastic Compute Cloud (Amazon EC2), esamina il valore expire_logs_days. Per ulteriori informazioni, consulta expire logs days (Giorni di conservazione dei log) sul sito web MySQL.

Nota: è consigliabile impostare il parametro globale della variabile SET su 1 o più. Per ulteriori informazioni, consulta SET syntax for variable assignment (Sintassi SET per l'assegnazione delle variabili) sul sito web MySQL.

Database MySQL gestiti da AWS

Controlla le ore di conservazione dei log binari impostate per un database Amazon Relational Database Service (Amazon RDS) per MySQL o Amazon Aurora compatibile con MySQL. Esegui questo comando:

mysql> call mysql.rds_show_configuration;

Per prolungare la conservazione dei log a 24 ore, esegui questo comando:

mysql> call mysql.rds_set_configuration('binlog retention hours', 24);

"Log event entry exceeded max_allowed_packet; increase max_allowed_packet on master..."

Esempio di errore nei log delle attività:

[SOURCE_CAPTURE  ]I:  Position was set in binlog 'mysql-bin.056367' at 787323674  (mysql_endpoint_capture.c:922)
[SOURCE_CAPTURE  ]D:  net_safe_read error 1236 (log event entry exceeded max_allowed_packet; Increase max_allowed_packet on master; the first event 'mysql-bin.056367' at 787323674, the last event read from '/mnt/data/logs/mysql-bin.056367' at 123, the last byte read from '/mnt/data/logs/mysql-bin.056367' at 787323693.)  (mysql_endpoint_capture.c:1119)
[SOURCE_CAPTURE  ]I:  Error 1236 (log event entry exceeded max_allowed_packet; Increase max_allowed_packet on master; the first event 'mysql-bin.056367' at 787323674, the last event read from '/mnt/data/logs/mysql-bin.056367' at 123, the last byte read from '/mnt/data/logs/mysql-bin.056367' at 787323693.) reading binlog. Try reconnect  (mysql_endpoint_capture.c:1123)

L'errore precedente può verificarsi per i seguenti motivi:

  • Una riga contiene più dati del valore del pacchetto max_allowed_packet nell'origine. Per ulteriori informazioni, consulta max allowed packet sul sito web MySQL.
  • Una singola transazione contiene grandi quantità di dati o sono presenti più aggiornamenti di riga in una singola transazione.
  • Il log binario nel database di origine è danneggiato.

Se utilizzi colonne BLOB (Binary Large Object) o stringhe lunghe, imposta il valore max_allowed_packet sul BLOB più grande che utilizzi. Il parametro può avere un valore fino a 1 GB. Per ulteriori informazioni, consulta The BLOB and TEXT types (Tipi di BLOB e TEXT) sul sito web MySQL.

Per verificare l'entità della transazione più importante, rivedi i log binari. Assicurati che la dimensione della transazione non superi la dimensione del pacchetto max_allowed_packet. Per informazioni sulla suddivisione di una transazione di grandi dimensioni, consulta Packet too large (Pacchetto troppo grande) sul sito web MySQL.

Se l'errore persiste, potrebbe esserci un danneggiamento nei log binari di origine.

Per verificare la presenza di problemi nei log binari, completa i seguenti passaggi:

  1. Esegui questo comando per verificare se il log binario esiste:

    mysql> SHOW BINARY LOGS;
  2. Per visualizzare gli eventi del log binario, esegui questo comando:

    mysql> SHOW BINLOG EVENTS IN 'binlog file' FROM position;

    Nota: sostituisci binlog file con il nome del log binario e position con la posizione in cui si verifica l'evento.

  3. Per scaricare i log binari, esegui il questo comando:

    shell> mysqlbinlog \
        --read-from-remote-server \
        --host=MySQLInstance1.cg034hpkmmjt.region.rds.amazonaws.com \
        --port=3306  \
        --user ReplUser \
        --password \
        --raw \
        --verbose \
        --result-file=/tmp/ \
        binlog.00098
  4. Controlla il log binario indicato nel messaggio di errore per verificare che non sia danneggiato.

  5. Se il log binario è danneggiato, invia una richiesta di assistenza al Supporto AWS.

"Binlog truncated in the middle of event; consider out of disk space on master..."

Esempio di errore nei log delle attività:

[SOURCE_CAPTURE ]I: Read next binary log event failed; net_safe_read error 1236 (binlog truncated in the middle of event; consider out of disk space on master; the first event 'mysql-bin-changelog.017672' at 486, the last event read from '/rdsdbdata/log/binlog/mysql-bin-changelog.017672' at 125, the last byte read from '/rdsdbdata/log/binlog/mysql-bin-changelog.017672' at 4756.) (mysql_endpoint_capture.c:1069)
[SORTER ]I: Transaction consistency reached (sorter_transaction.c:347)
[TASK_MANAGER ]I: Starting replication now (replicationtask.c:2774)
[TASK_MANAGER ]I: Task - MGLVRIRUJH6FE2GP6F7SW46BPBW6YKF2JUJPSVY is in RUNNING state, updating starting status to AR_RUNNING (repository.c:5110)

L'errore precedente può verificarsi per i seguenti motivi:

  • È presente l'impostazione sync_binlog != 1 sul server primario. Ciò significa che gli eventi del log binario potrebbero non essere sincronizzati sul disco. Per ulteriori informazioni, consulta sync binlog sul sito web MySQL.
  • Il log binario nel database di origine è danneggiato.

Per risolvere l'errore, assicurati che il valore del parametro sync_binlog nell'origine sia impostato su 1. Poi riavvia l'attività.

Nel caso in cui il parametro sync_binlog sia già impostato su 1, controlla se il log binario è danneggiato. Per istruzioni, consulta la sezione precedente "Log event entry exceeded max_allowed_packet; increase max_allowed_packet on master...".

"Client requested master to start replication from impossible position"

Esempio di errore nei log delle attività:

[SOURCE_CAPTURE  ]I:  Position was set in binlog 'mysql-bin-changelog.007989' at 1631  (mysql_endpoint_capture.c:922)
[SOURCE_CAPTURE  ]I:  Read next binary log event failed; net_safe_read error 1236 (Client requested master to start replication from impossible position; the first event 'mysql-bin-changelog.007989' at 1631, the last event read from 'mysql-bin-changelog.007989' at 4, the last byte read from 'mysql-bin-changelog.007989' at 4.)  (mysql_endpoint_capture.c:1053)
[SOURCE_CAPTURE  ]D:  Error reading binary log. [1020493]  (mysql_endpoint_capture.c:3995)
[SOURCE_CAPTURE  ]E:  Error 1236 (Client requested master to start replication from impossible position; the first event 'mysql-bin-changelog.007989' at 1631, the last event read from 'mysql-bin-changelog.007989' at 4, the last byte read from 'mysql-bin-changelog.007989' at 4.) reading binlog events [1020493]  (mysql_endpoint_capture.c:1074)

L'errore si verifica quando il server del database MySQL di origine si arresta in modo imprevisto. Un arresto imprevisto potrebbe verificarsi a causa di un guasto hardware, ad esempio un errore del disco o un'interruzione dell'alimentazione.

Per risolvere l'errore, intraprendi una delle seguenti azioni in base al tipo di attività AWS DMS:

  • Per attività di caricamento completo e CDC, riavvia l'attività AWS DMS.
  • Per attività solo CDC, avvia l'attività AWS DMS dalla posizione successiva del log binario.

"Client requested master to start replication from position > file size"

Esempio di errore nei log delle attività:

[SOURCE_CAPTURE  ]I:  Position was set in binlog 'binlog.000012' at 2179  (mysql_endpoint_capture.c:922)
[SOURCE_CAPTURE  ]I:  Read next binary log event failed; net_safe_read error 1236 (Client requested master to start replication from position > file size)  (mysql_endpoint_capture.c:1052

L'errore può verificarsi a causa di log binari crittografati. Se il database MySQL di origine esegue MySQL versione 8.0 e crittografi i log binari, AWS DMS non è in grado di leggere i log all'inizializzazione dell'attività. Di conseguenza, AWS DMS registra questo errore. Quando attivi la crittografia dei log binari, non puoi utilizzare la replica CDC che utilizza MySQL 8.0 come origine. Per ulteriori informazioni, consulta Encrypting Binary Log Files and Relay Log Files (Crittografia di file di log binari e file di log di inoltro) sul sito web MySQL.

Per risolvere il problema, completa i seguenti passaggi:

  1. Esegui questo comando per verificare la versione di MySQL:

    mysql> SELECT VERSION();
  2. Esegui questo comando per verificare se l’opzione binlog_encryption è attivata:

    mysql> SELECT * FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'binlog_encryption';
  3. Per disattivare ** binlog\ _encryption**, esegui il comando seguente:

    mysql> SET GLOBAL binlog_encryption = OFF;

    -oppure-
    Avvia l'attività AWS DMS con l'opzione binlog_encryption disattivata, quindi esegui questo comando per attivare binlog_encryption:

    mysql> SET GLOBAL binlog_encryption = ON;

Informazioni correlate

Come posso risolvere gli errori di registrazione binaria che ricevo quando utilizzo AWS DMS con Aurora compatibile con MySQL come origine?