Utilizzo di un'importazione gestita per configurare la replica da database esterni

Questa pagina descrive come configurare e utilizzare un'importazione gestita per i dati durante la replica da un server esterno a Cloud SQL.

Devi completare tutti i passaggi descritti in questa pagina. Al termine, puoi amministrare e monitorare l'istanza di rappresentazione dell'origine allo stesso modo di qualsiasi altra istanza Cloud SQL.

Prima di iniziare

Prima di iniziare, completa questi passaggi:

  1. Configura il server esterno.

  2. Crea l'istanza di rappresentazione dell'origine.

  3. Configura la replica Cloud SQL.

Aggiorna i privilegi per l'utente di replica

L'utente di replica sul server esterno è configurato per accettare connessioni da qualsiasi host (%). Aggiorna questo account utente in modo che possa essere utilizzato solo con la replica Cloud SQL.

Privilegi obbligatori

Esistono quattro tipi di combinazioni di migrazioni e dump.

  • Tipo 1: migrazione continua e dump gestito
  • Tipo 2: migrazione continua e dump manuale
  • Tipo 3: migrazione una tantum e dump gestito
  • Tipo 4: migrazione una tantum e dump manuale

Di seguito sono elencati i privilegi per ogni tipo di migrazione e combinazione semplice.

Tipo 1

L'account utente deve disporre dei seguenti privilegi:

Per MySQL versione 8.0 e successive, è consigliabile ignorare il privilegio BACKUP ADMIN per prestazioni ottimali.

Tipo 2

L'account utente deve disporre dei seguenti privilegi:

Tipo 3

L'account utente deve disporre dei seguenti privilegi:

Per MySQL versione 8.0 e successive, è consigliabile ignorare il privilegio BACKUP ADMIN per prestazioni ottimali.

Tipo 4

Non sono richiesti privilegi.

Aggiorna privilegi

Per aggiornare i privilegi, apri un terminale sul server esterno e inserisci i seguenti comandi.

Client MySQL

Per GTID: 

    UPDATE mysql.user
      SET Host='NEW_HOST'
      WHERE Host='OLD_HOST'
      AND User='USERNAME';
    GRANT REPLICATION SLAVE, EXECUTE, SELECT, SHOW VIEW, REPLICATION_CLIENT,
    RELOAD ON . TO
    'USERNAME'@'HOST';
    FLUSH PRIVILEGES;

Per binlog: 

    UPDATE mysql.user
    SET Host='NEW_HOST'
    WHERE Host='OLD_HOST'
    AND User='USERNAME';
    GRANT REPLICATION SLAVE, EXECUTE, SELECT, SHOW VIEW, REPLICATION CLIENT,
    RELOAD ON . TO 'GCP_USERNAME'@'HOST';
    FLUSH PRIVILEGES;

esempio 

UPDATE mysql.user
  SET Host='192.0.2.0'
  WHERE Host='%'
  AND User='replicationUser';
GRANT REPLICATION SLAVE, EXECUTE, SELECT, SHOW VIEW, REPLICATION CLIENT,
RELOAD ON *.* TO 'username'@'host.com';
FLUSH PRIVILEGES;
Proprietà Descrizione
NEW_HOST Specifica l'IP in uscita della replica Cloud SQL.
OLD_HOST Il valore corrente assegnato a Host che vuoi modificare.
USERNAME L'account utente di replica sul server esterno.
GCP_USERNAME Il nome utente dell'account utente.
HOST Il nome host dell'account utente.

Verificare le impostazioni di replica

Una volta completata la configurazione, assicurati che la replica Cloud SQL possa replicare dal server esterno.

Le seguenti impostazioni di sincronizzazione esterna devono essere corrette.

  • Connettività tra la replica Cloud SQL e il server esterno
  • Privilegi utente di replica
  • Compatibilità delle versioni
  • La replica Cloud SQL non è già in fase di replica
  • I log binari sono attivati sul server esterno
  • GTID è abilitato se stai tentando di eseguire una sincronizzazione esterna da un server esterno RDS e stai utilizzando un bucket Google Cloud

Per verificare queste impostazioni, apri un terminale Cloud Shell e inserisci i seguenti comandi:

curl 

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "SYNC_MODE",
         "syncParallelLevel": "SYNC_PARALLEL_LEVEL",
         "mysqlSyncConfig": {
           "initialSyncFlags": "SYNC_FLAGS"
         }
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_INSTANCE_ID/verifyExternalSyncSettings

esempio 

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "online",
         "syncParallelLevel": "optimal"
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/myproject/instances/myreplica/verifyExternalSyncSettings

Esempio con flag di sincronizzazione 

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "online",
         "syncParallelLevel": "optimal"
         "mysqlSyncConfig": {
             "initialSyncFlags": [{"name": "max-allowed-packet", "value": "1073741824"}, {"name": "hex-blob"}, {"name": "compress"}]
             }
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/MyProject/instances/replica-instance/verifyExternalSyncSettings

Queste chiamate restituiscono un elenco di tipo sql#externalSyncSettingErrorList.

Se l'elenco è vuoto, non sono presenti errori. Una risposta senza errori è simile alla seguente:

  {
    "kind": "sql#externalSyncSettingErrorList"
  }
Proprietà Descrizione
SYNC_MODE Assicurati di poter mantenere sincronizzate la replica Cloud SQL e il server esterno dopo la configurazione della replica. Le modalità di sincronizzazione includono EXTERNAL_SYNC_MODE_UNSPECIFIED, ONLINE e OFFLINE.
SYNC_PARALLEL_LEVEL

Verifica l'impostazione che controlla la velocità di trasferimento dei dati dalle tabelle di un database. Sono disponibili i seguenti valori:

  • min: Utilizza la quantità minima di risorse di calcolo sul database. Questa è la velocità più bassa per il trasferimento dei dati.
  • optimal: Offre prestazioni bilanciate con un carico ottimale sul database.
  • max: Offre la massima velocità per il trasferimento dei dati, ma potrebbe causare un aumento del carico sul database.

Nota:il valore predefinito di questo parametro è optimal perché questa impostazione offre una buona velocità di trasferimento dei dati e ha un impatto ragionevole sul database. Ti consigliamo di utilizzare questo valore.
SYNC_FLAGS Un elenco di flag di sincronizzazione iniziale da verificare. Consigliato solo se prevedi di utilizzare flag di sincronizzazione personalizzati durante la replica dall'origine. Per un elenco dei flag consentiti, vedi Flag di sincronizzazione iniziale.
PROJECT_ID L'ID del tuo progetto Google Cloud .
REPLICA_INSTANCE_ID L'ID della replica Cloud SQL.

Autorizzazione di blocco in lettura globale

Se non disponi dell'autorizzazione per accedere al blocco di lettura globale sul server esterno, come potrebbe accadere con Amazon RDS e Amazon Aurora, metti in pausa le scritture sul server come descritto nei passaggi seguenti:

  1. Vai a Esplora log e seleziona la replica Cloud SQL dall'elenco delle risorse. Dovresti visualizzare un elenco dei log più recenti per la replica Cloud SQL. Ignorali per il momento.
  2. Apri un terminale e inserisci i comandi in Avvia la replica sul server esterno per eseguire la replica dal server esterno.

  3. Torna a Esplora log. Quando vedi il log come segue, interrompi la scrittura nel database sul server esterno. Nella maggior parte dei casi, questa operazione è richiesta solo per pochi secondi.

       DUMP_IMPORT(START): Start importing data, please pause any write to the
   external primary database.

  4. Quando visualizzi la seguente voce di log in Esplora log, riattiva la scrittura nel database sul server esterno.

       DUMP_IMPORT(SYNC): Consistent state on primary and replica. Writes to the
   external primary may resume.

Avvia la replica sul server esterno

Dopo aver verificato di poter eseguire la replica dal server esterno, avviala. La velocità di esecuzione della replica per il processo di importazione iniziale è fino a 500 GB all'ora. Tuttavia, questa velocità può variare in base al livello della macchina, alle dimensioni del disco di dati, al throughput di rete e alla natura del database.

Durante il processo di importazione iniziale, non eseguire operazioni DDL sul server esterno. In caso contrario, potrebbero verificarsi incoerenze durante l'importazione. Al termine del processo di importazione, la replica utilizza i log binari sul server esterno per raggiungere lo stato attuale del server esterno.

curl 

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "SYNC_MODE",
         "skipVerification": "SKIP_VERIFICATION",
         "syncParallelLevel": "SYNC_PARALLEL_LEVEL",
         "mysqlSyncConfig": {
           "initialSyncFlags": "SYNC_FLAGS"
         }
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_INSTANCE_ID/startExternalSync

esempio 

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "online",
         "syncParallelLevel": "optimal"
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/MyProject/instances/replica-instance/startExternalSync

Esempio con flag di sincronizzazione 

gcloud auth login
ACCESS_TOKEN="$(gcloud auth print-access-token)"
curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
     --header 'Content-Type: application/json' \
     --data '{
         "syncMode": "online",
         "syncParallelLevel": "optimal"
         "skipVerification": false,
         "mysqlSyncConfig": {
             "initialSyncFlags": [{"name": "max-allowed-packet", "value": "1073741824"}, {"name": "hex-blob"}, {"name": "compress"}]
             }
       }' \
     -X POST \
     https://sqladmin.googleapis.com/sql/v1beta4/projects/MyProject/instances/replica-instance/startExternalSync
Proprietà Descrizione
SYNC_MODE Verifica di poter mantenere sincronizzate la replica Cloud SQL e il server esterno dopo la configurazione della replica.
SKIP_VERIFICATION Se saltare il passaggio di verifica integrato prima di sincronizzare i dati. Questo parametro è consigliato solo se hai già verificato le impostazioni di replica.
SYNC_PARALLEL_LEVEL

Fornisci un'impostazione che controlli la velocità di trasferimento dei dati dalle tabelle di un database. Sono disponibili i seguenti valori:

  • min: Utilizza la quantità minima di risorse di calcolo sul database. Questa è la velocità più bassa per il trasferimento dei dati.
  • optimal: Offre prestazioni bilanciate con un carico ottimale sul database.
  • max: Offre la massima velocità per il trasferimento dei dati, ma potrebbe causare un aumento del carico sul database.

Nota:il valore predefinito di questo parametro è optimal perché questa impostazione offre una buona velocità di trasferimento dei dati e ha un impatto ragionevole sul database. Ti consigliamo di utilizzare questo valore.
SYNC_FLAGS Un elenco di flag di sincronizzazione iniziale da verificare. Consigliato solo se prevedi di utilizzare flag di sincronizzazione personalizzati durante la replica dall'origine. Per un elenco dei flag consentiti, vedi Flag di sincronizzazione iniziale.
PROJECT_ID L'ID del tuo progetto Google Cloud .
REPLICA_INSTANCE_ID L'ID della replica Cloud SQL.

Flag sincronizzazione iniziale

Per eseguire la migrazione con flag di database personalizzati, puoi utilizzare i seguenti flag consentiti:

  • --add-drop-database
  • --add-drop-table
  • --add-drop-trigger
  • --add-locks
  • --allow-keywords
  • --all-tablespaces
  • --apply-slave-statements
  • --column-statistics
  • --comments
  • --compact
  • --compatible
  • --complete-insert
  • --compress
  • --compression-algorithms
  • --create-options
  • --default-character-set
  • --delayed-insert
  • --disable-keys
  • --dump-date
  • --events
  • --extended-insert
  • --fields-enclosed-by
  • --fields-escaped-by
  • --fields-optionally-enclosed-by
  • --fields-terminated-by
  • --flush-logs
  • --flush-privileges
  • --force
  • --get-server-public-key
  • --hex-blob
  • --ignore-error
  • --ignore-read-lock-error
  • --ignore-table
  • --insert-ignore
  • --lines-terminated-by
  • --lock-all-tables
  • --lock-tables
  • --max-allowed-packet
  • --net-buffer-length
  • --network-timeout
  • --no-autocommit
  • --no-create-db
  • --no-create-info
  • --no-data
  • --no-defaults
  • --no-set-names
  • --no-tablespaces
  • --opt
  • --order-by-primary
  • --pipe
  • --quote-names
  • --quick
  • --replace
  • --routines
  • --secure-auth
  • --set-charset
  • --shared-memory-base-name
  • --show-create-skip-secondary-engine
  • --skip-opt
  • --ssl-cipher
  • --ssl-fips-mode
  • --ssl-verify-server-cert
  • --tls-ciphersuites
  • --tls-version
  • --triggers
  • --tz-utc
  • --verbose
  • --xml
  • --zstd-compression-level

Per i valori consentiti, consulta la documentazione pubblica di MySQL.

Monitoraggio della migrazione

Una volta avviata la replica dal server esterno, devi monitorarla. Per saperne di più, consulta Monitoraggio della replica. A questo punto puoi completare la migrazione.

Risoluzione dei problemi

Valuta le seguenti opzioni per la risoluzione dei problemi:

Problema Risoluzione dei problemi
La replica di lettura non ha iniziato la replica al momento della creazione. Probabilmente nei file di log è presente un errore più specifico. Ispeziona i log in Cloud Logging per trovare l'errore effettivo.
Impossibile creare la replica di lettura - errore invalidFlagValue. Uno dei flag nella richiesta non è valido. Potrebbe trattarsi di un flag che hai fornito esplicitamente o di uno impostato su un valore predefinito.

Innanzitutto, verifica che il valore del flag max_connections sia maggiore o uguale al valore dell'istanza principale.

Se il flag max_connections è impostato correttamente, esamina i log in Cloud Logging per trovare l'errore effettivo.
Impossibile creare la replica di lettura. Errore sconosciuto. Probabilmente nei file di log è presente un errore più specifico. Ispeziona i log in Cloud Logging per trovare l'errore effettivo.

Se l'errore è: set Service Networking service account as servicenetworking.serviceAgent role on consumer project, disattiva e riattiva Service Networking API. Questa azione crea il account di servizio necessario per continuare la procedura.
Lo spazio sul disco è esaurito. La dimensione del disco dell'istanza principale può esaurirsi durante la creazione della replica. Modifica l'istanza principale per eseguire l'upgrade a una dimensione del disco maggiore.
L'istanza di replica utilizza troppa memoria. La replica utilizza la memoria temporanea per memorizzare nella cache le operazioni di lettura richieste di frequente, il che può portare a un utilizzo di memoria superiore rispetto all'istanza principale.

Riavvia l'istanza di replica per recuperare lo spazio di memoria temporaneo.
La replica è stata interrotta. È stato raggiunto il limite massimo di spazio di archiviazione e l'aumento automatico dello spazio di archiviazione non è abilitato.

Modifica l'istanza per abilitare automatic storage increase.
Il ritardo di replica è costantemente elevato. Il carico di scrittura è troppo elevato per la replica. Il ritardo di replica si verifica quando il thread SQL su una replica non riesce a tenere il passo con il thread I/O. Alcuni tipi di query o carichi di lavoro possono causare un ritardo di replica elevato temporaneo o permanente per un determinato schema. Alcune delle cause tipiche del ritardo della replica sono:
  • Query lente sulla replica. Trova e correggi gli errori.
  • Tutte le tabelle devono avere una chiave univoca/primaria. Ogni aggiornamento di una tabella senza una chiave univoca/primaria causa scansioni complete della tabella sulla replica.
  • Query come DELETE ... WHERE field < 50000000 causano un ritardo della replica con la replica basata su righe, poiché un numero elevato di aggiornamenti si accumula nella replica.

Alcune possibili soluzioni includono:
Il ritardo della replica aumenta improvvisamente. Ciò è dovuto a una o più transazioni a lunga esecuzione. Quando una transazione (singola istruzione o più istruzioni) viene eseguita nell'istanza di origine, l'ora di inizio della transazione viene registrata nel log binario. Quando la replica riceve questo evento binlog, confronta il timestamp con il timestamp corrente per calcolare il ritardo di replica. Pertanto, una transazione a lunga esecuzione sull'origine comporterebbe un ritardo di replica immediato e di grandi dimensioni sulla replica. Se la quantità di modifiche alle righe nella transazione è elevata, anche la replica impiegherà molto tempo per eseguirla. Durante il periodo di tempo, il ritardo della replica aumenta. Una volta completata questa transazione, il periodo di recupero dipenderà dal carico di lavoro di scrittura sull'origine e dalla velocità di elaborazione della replica.

Per evitare una transazione lunga, alcune possibili soluzioni includono:

  • Suddividi la transazione in più transazioni di piccole dimensioni
  • Dividi una singola query di scrittura di grandi dimensioni in batch più piccoli
  • Prova a separare le query SELECT lunghe da una transazione mista con DML
La modifica dei flag di replica parallela genera un errore. È stato impostato un valore errato per uno o più di questi flag.

Nell'istanza principale che mostra il messaggio di errore, imposta i flag di replica parallela:

  1. Modifica i flag binlog_transaction_dependency_tracking e transaction_write_set_extraction:
    • binlog_transaction_dependency_tracking=COMMIT_ORDER
    • transaction_write_set_extraction=OFF
  2. Aggiungi il flag slave_pending_jobs_size_max:

    slave_pending_jobs_size_max=33554432

  3. Modifica il flag transaction_write_set_extraction:

    transaction_write_set_extraction=XXHASH64

  4. Modifica il flag binlog_transaction_dependency_tracking:

    binlog_transaction_dependency_tracking=WRITESET
La creazione della replica non riesce a causa del timeout. Le transazioni non sottoposte a commit a esecuzione prolungata sull'istanza principale possono causare la mancata creazione della replica di lettura.

Ricrea la replica dopo aver interrotto tutte le query in esecuzione.

Inoltre, per MySQL, prendi in considerazione anche le seguenti opzioni:

Problema Risoluzione dei problemi
Lost connection to MySQL server during query when dumping table. La fonte potrebbe non essere più disponibile o il dump conteneva pacchetti troppo grandi.

Assicurati che la primaria esterna sia disponibile per la connessione. Puoi anche modificare i valori dei flag net_read_timeout e net_write_timeout nell'istanza di origine per interrompere l'errore. Per ulteriori informazioni sui valori consentiti per questi flag, consulta la pagina Configurare i flag di database.

Per scoprire di più sull'utilizzo dei flag mysqldump per la migrazione dell'importazione gestita, vedi Flag di sincronizzazione iniziale consentiti e predefiniti
La migrazione iniziale dei dati è stata completata, ma non vengono replicati dati. Una possibile causa principale potrebbe essere che il database di origine ha definito flag di replica che comportano la mancata replica di alcune o di tutte le modifiche al database.

Assicurati che i flag di replica come binlog-do-db, binlog-ignore-db, replicate-do-db o replicate-ignore-db non siano impostati in modo conflittuale.

Esegui il comando show master status sull'istanza primaria per visualizzare le impostazioni correnti.
La migrazione iniziale dei dati è stata completata, ma la replica dei dati smette di funzionare dopo un po' di tempo. Tentativi da effettuare

  • Controlla le metriche di replica per l'istanza di replica nella sezione Cloud Monitoring della console Google Cloud .
  • Gli errori del thread I/O o SQL di MySQL sono disponibili in Cloud Logging nei file mysql.err log.
  • L'errore può essere rilevato anche durante la connessione all'istanza di replica. Esegui il comando SHOW SLAVE STATUS e controlla i seguenti campi nell'output:
    • Slave_IO_Running
    • Slave_SQL_Running
    • Last_IO_Error
    • Last_SQL_Error
mysqld check failed: data disk is full. Il disco dati dell'istanza di replica è pieno.

Aumenta le dimensioni del disco dell'istanza di replica. Puoi aumentare manualmente le dimensioni del disco o attivare l'aumento automatico dello spazio di archiviazione.

Esaminare i log di replica

Quando verifichi le impostazioni di replica, vengono prodotti i log.

Per visualizzare questi log, procedi nel seguente modo:

  1. Vai al visualizzatore log nella console Google Cloud .

    Vai al visualizzatore log

  2. Seleziona la replica Cloud SQL dal menu a discesa Istanza.
  3. Seleziona il file di log replication-setup.log.

Se la replica Cloud SQL non riesce a connettersi al server esterno, verifica quanto segue:

  • Qualsiasi firewall sul server esterno è configurato per consentire le connessioni dall'indirizzo IP in uscita della replica Cloud SQL.
  • La configurazione SSL/TLS è corretta.
  • L'utente di replica, l'host e la password siano corretti.

Passaggi successivi