Documentazione dell'infrastruttura Oracle Cloud

Risoluzione dei problemi relativi alla replica in entrata

Risoluzione degli errori di replica in entrata

Isolare gli errori di replica in entrata recuperando informazioni correlate alla replica in entrata.

Uso della shell MySQL

Utilizzare la shell MySQL o un programma client MySQL per recuperare informazioni correlate alla replica in entrata.

Questa attività richiede quanto segue:
  • Sistema DB di replica in esecuzione.
  • Shell MySQL o programma client MySQL connesso al sistema DB di replica.
Eseguire uno o più dei comandi riportati di seguito nel sistema DB di replica per recuperare le informazioni correlate alla replica in entrata.
  • SHOW REPLICA STATUS \G

    Mostra informazioni sullo stato dei parametri essenziali dei thread di replica. Vedere SHOW REPLICA STATUS.

  • SELECT * FROM performance_schema.replication_connection_status \G

    Mostra lo stato corrente del thread di I/O che gestisce la connessione della replica all'origine. Vedere replication_connection_status.

  • SELECT * FROM performance_schema.replication_applier_status_by_worker \G

    Mostra i dettagli delle transazioni gestite dai thread degli applier su una replica. Vedere replication_applier_status_by_worker.

Codici errore ricevente replica in entrata

Questa tabella mostra alcuni dei codici di errore comuni del ricevente della replica in entrata.

Tabella 22-4 Codici di errore del ricevente della replica in entrata

Codice di errore descrizione;
MY-1045: ER_ACCESS_DENIED_ERROR; Access denied for user '%s'@'%s'
  • Il nome utente o la password di origine sono errati. Controllare le proprie credenziali.
  • L'utente non dispone dell'autorizzazione per accedere all'origine. Controllare l'origine e assicurarsi che l'utente della replica sia configurato correttamente.
MY-1227 (42000): Access denied; you need (at least one of) the SUPER or SET_USER_ID privilege(s) for this operation È possibile effettuare una delle seguenti operazioni:
  • Specificare lo stesso nome utente in DEFINER e Nome utente dell'applicazione. È necessario disporre del privilegio SET_USER_ID solo quando i nomi utente in DEFINER e nome utente dell'applicazione sono diversi. Vedere Creazione di un canale di replica.
  • Contattare il Supporto Oracle per concedere il privilegio SET_USER_ID al nome utente dell'applicazione.
MY-1236: ER_MASTER_FATAL_ERROR_READING_BINLOG Got fatal error %d from master when reading data from binary log: '%s' Vedere Risoluzione dell'errore irreversibile 1236.
MY-2003: Network connection has been refused Nome host e porta non sono corretti oppure l'origine non è in esecuzione. Controllare il nome host e la porta definiti e verificare che l'origine sia in esecuzione.
MY-3159: ER_SECURE_TRANSPORT_REQUIRED Connections using insecure transport are prohibited while --require_secure_transport=ON Il sorgente richiede una connessione sicura. Confermare di aver selezionato una delle opzioni SSL quando è stato definito il canale.
Per la lista completa dei messaggi di errore MySQL, vedere Riferimento ai messaggi di errore del server.

Codici di errore dell'applicatore di replica in entrata

Questa tabella mostra alcuni dei codici di errore comuni dell'applier di replica in entrata.

Tabella 22-5 Codici di errore dell'applicatore di replica in entrata

Codice di errore descrizione;
  • MY-1146: ER_NO_SUCH_TABLE;
  • MY-1032: HA_ERR_KEY_NOT_FOUND
  • MY-1062: HA_ERR_FOUND_DUPP_KEY
  • MY-1064: ERROR IN SQL syntax
  • MY-1050: ER_TABLE_EXISTS_ERROR
  • MY-1051: ER_BAD_TABLE_ERROR
  • MY-1146: ER_NO_SUCH_TABLE
  • MY-1007: ER_DB_CREATE_EXISTS
  • MY-1054: ER_BAD_FIELD_ERROR

Questi errori si verificano se i dati della replica non sono più sincronizzati con l'origine. Ciò può verificarsi se i dati della replica sono stati modificati manualmente, ad esempio.

Per correggere questi errori, è necessario risincronizzare l'origine e la replica e riprendere il canale di replica.

MY-1205: ER_LOCK_WAIT_TIMEOUT Timeout superato. Per correggere questo errore, riprendere il canale di replica. Vedere Ripresa di un canale.
MY-1595/ MY-013121: RELAY LOG READ FAILURE Il log relè è danneggiato e non può essere letto. Per correggere questo errore, reimpostare il canale di replica. Vedere Reimpostazione di un canale.
Per la lista completa dei messaggi di errore MySQL, vedere Riferimento ai messaggi di errore del server.

Risoluzione errore fatale 1236

Si verifica l'errore quando il set GTID dal dump logico non viene applicato al sistema DB o i log binari sono stati rimossi dall'origine. I log binari sono un requisito obbligatorio per la replica.

Uso della shell MySQL

Utilizzare la shell MySQL per risolvere il file Fatal Error 1236 ottenuto durante l'esecuzione della replica in entrata.

In questa attività si presuppone che:
  • Si ottiene Fatal Error 1236 durante l'esecuzione della replica in entrata: 
    Got fatal error 1236 from master when reading data from binary log: 'The slave is connecting
      using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs
      containing GTIDs that the slave requires.

Nell'handshake di connessione iniziale, la replica (sistema DB) invia un set GTID contenente le transazioni già ricevute, sottoposte a commit o entrambe. L'origine risponde inviando tutte le transazioni registrate nel proprio log binario il cui GTID non è incluso nel set GTID inviato dalla replica. Questo scambio garantisce che l'origine invii solo le transazioni con un GTID che la replica non ha già registrato o impegnato.

Per risolvere il problema, effettuare le operazioni riportate di seguito.

Risoluzione dei problemi di sincronizzazione di replica e origine

I problemi di sincronizzazione si verificano quando la replica è rimasta indietro rispetto all'origine e la replica è irreversibile.

Nota

Prima di tentare il recupero da questo errore, si consiglia di verificare il motivo dell'errore e di eseguire un'azione correttiva.

Uso della shell MySQL

Utilizzare la shell MySQL per risolvere i problemi di sincronizzazione della replica e dell'origine.

In questa attività si presuppone che:
  • L'origine e la replica della replica in entrata non sono più sincronizzate, la replica è rimasta molto indietro rispetto all'origine e la replica è irreversibile.
Nota

Se i valori gtid di origine vengono reimpostati su un valore inferiore rispetto a quelli della replica, se nell'origine è stato emesso un reset master errato, ad esempio la replica in entrata non è recuperabile. In questo scenario, ricreare il sistema DB e la configurazione della replica in entrata.
Per risincronizzare la replica con l'origine, effettuare le operazioni riportate di seguito.
  1. Arrestare il canale di replica esistente e sospendere tutte le transazioni nell'origine.
  2. Esporta i dati di origine nello storage degli oggetti. Fare riferimento a Esportazione di un'istanza MySQL.
  3. Rimuovere gli oggetti di database precedenti e i database preesistenti nella replica.
  4. Importare il dump dallo storage degli oggetti nel sistema DB. Vedere Importazione mediante la shell MySQL.
  5. Recuperare il valore gtidExecuted dalla replica.
  6. Recuperare il valore gtidExecuted dal file @.json del dump di origine.
  7. Confrontare il file gtidExecuted della replica con il dump di origine gtidExecuted per ottenere il delta gtidExecuted.
    Ad esempio, se il valore gtidExecuted del dump di origine è serverUUID: 1-2000 e gtidExecuted della replica è serverUUID:1-1000, il valore delta è 1001-2000.
  8. Connettersi alla replica dalla riga di comando e applicare il delta alla replica utilizzando la stored procedure CALL sys.SET_GTID_PURGED("+<ServerUUID>:<DeltaValue>).
    Ad esempio, utilizzando il valore delta mostrato nell'esempio precedente: 
    call sys.SET_GTID_PURGED("+<ServerUUID>:1001-2000")
  9. Al termine del processo, riprendere il canale di replica.