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 della rappresentazione di origine come faresti con qualsiasi altra istanza Cloud SQL.
Prima di iniziare
Prima di iniziare, completa questi passaggi:
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 combinazione di migrazione e dumb.
Tipo 1
L'account utente deve disporre dei seguenti privilegi:
- SCHIERA DELLA RISPOSTA
- ESEGUI
- SELECT
- MOSTRA VISUALIZZAZIONE
- CLIENTE DI RISPOSTA
- RICARICA
- ATTIVAZIONE
- (Solo per la migrazione da Amazon RDS e Amazon Aurora) TABELLE DI BLOCCA
Per MySQL versione 8.0 e successive, consigliamo di ignorare il privilegio BACKUP ADMIN
per ottenere prestazioni ottimali.
Tipo 2
L'account utente deve disporre dei seguenti privilegi:
Tipo 3
L'account utente deve disporre dei seguenti privilegi:
- SELECT
- MOSTRA VISUALIZZAZIONE
- ATTIVAZIONE
- (Solo dalla migrazione dalle origini con l'impostazione
GTID_MODE = ON
) RELOAD
Per MySQL versione 8.0 e successive, consigliamo di ignorare il privilegio BACKUP ADMIN
per ottenere prestazioni ottimali.
Tipo 4
Non sono necessari 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 il 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;
un 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. |
Verifica le impostazioni di replica
Al termine della configurazione, assicurati che la replica Cloud SQL possa replicarsi dal server esterno.
Le seguenti impostazioni di sincronizzazione esterna devono essere corrette.
- Connettività tra la replica di Cloud SQL e il server esterno
- Privilegi utente per la replica
- Compatibilità delle versioni
- La replica Cloud SQL non è già in fase di replica
- I binlog sono abilitati 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:
arricciatura
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
un 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 ci sono errori. Una risposta senza errori sarà simile alla seguente:
{ "kind": "sql#externalSyncSettingErrorList" }
Proprietà | Descrizione |
---|---|
SYNC_MODE | Assicurati di poter mantenere sincronizzati 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à con cui vengono trasferiti i dati delle tabelle di un database. Sono disponibili i seguenti valori:
Nota: il valore predefinito di questo parametro è |
SYNC_FLAGS | Un elenco di flag di sincronizzazione iniziali da verificare. Opzione consigliata 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 tua replica Cloud SQL. |
Autorizzazione di blocco di lettura globale
Se non hai l'autorizzazione per accedere al blocco di lettura globale sul server esterno, come potrebbe essere nel caso di Amazon RDS e Amazon Aurora, metti in pausa le scritture sul server come descritto nei seguenti passaggi:
- 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. Per ora ignoralo.
- Apri un terminale e inserisci i comandi in Avvia la replica sul server esterno per replicarlo dal server esterno.
Torna a Esplora log. Quando vedi il log come segue, interrompi la scrittura sul database sul tuo server esterno. Nella maggior parte dei casi, questa operazione è necessaria solo per pochi secondi.
DUMP_IMPORT(START): Start importing data, please pause any write to the external primary database.
Quando vedi 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 replicare dal server esterno, avvia la replica. 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 di macchina, alle dimensioni del disco dati, alla velocità effettiva di rete e alla natura del database.
Durante il processo di importazione iniziale, non eseguire operazioni DDL sul server esterno. Ciò potrebbe causare incongruenze durante l'importazione. Al termine del processo di importazione, la replica utilizza i log binari sul server esterno per aggiornarsi allo stato attuale del server esterno.
arricciatura
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
un 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 sincronizzati la replica Cloud SQL e il server esterno dopo la configurazione della replica. |
SKIP_VERIFICATION | Indica 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 controlla la velocità di trasferimento dei dati delle tabelle di un database. Sono disponibili i seguenti valori:
Nota: il valore predefinito di questo parametro è |
SYNC_FLAGS | Un elenco di flag di sincronizzazione iniziali da verificare. Opzione consigliata 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 tua replica Cloud SQL. |
Flag di 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
- --commenti
- --compact
- --compatibile
- --complete-insert
- --compress
- --compression-algorithms
- --create-options
- --default-character-set
- --delayed-insert
- --disable-keys
- --dump-date
- --eventi
- --extended-insert
- --fields-enclosed-by
- --fields-escaped-by
- --fields-optionally-enclosed-by
- --fields-terminated-by
- --flush-logs
- --flush-privileges
- --forza
- --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
- --veloce
- --sostituire
- --routine
- --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
- --dettagliato
- --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. Puoi quindi completare la migrazione.
Risolvere i problemi
Prendi in considerazione le seguenti opzioni per la risoluzione dei problemi:
Problema | Risoluzione dei problemi |
---|---|
La replica di lettura non ha avviato la replica al momento della creazione. | È probabile che i file di log contengano un errore più specifico. Ispeziona i log in Cloud Logging per trovare l'errore effettivo. |
Impossibile creare la replica di lettura: errore non validoFlagValue. | Uno dei flag nella richiesta non è valido. Potrebbe essere un flag che hai fornito esplicitamente o un flag impostato su un valore predefinito.
Innanzitutto, verifica che il valore del flag Se il flag |
Impossibile creare la replica di lettura: errore sconosciuto. | È probabile che i file di log contengano un errore più specifico.
Ispeziona i log in Cloud Logging per trovare l'errore effettivo.
Se l'errore è: |
Lo spazio sul disco è esaurito. | La dimensione del disco dell'istanza principale può diventare piena durante la creazione della replica. Modifica l'istanza principale per eseguirne l'upgrade a una dimensione del disco più grande. |
L'istanza di replica utilizza troppa memoria. | La replica utilizza la memoria temporanea per memorizzare nella cache le operazioni di lettura più richieste, il che può portare a utilizzare più memoria rispetto all'istanza principale.
Riavvia l'istanza di replica per recuperare lo spazio di memoria temporaneo. |
Replica 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 |
Il ritardo della replica è costantemente elevato. | Il carico di scrittura è troppo elevato per essere gestito dalla replica. Il ritardo della replica si verifica quando il thread SQL su una replica non è in grado di stare al passo con il thread di IO. 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 più comuni del ritardo di replica sono:
Ecco alcune possibili soluzioni:
|
Il ritardo della replica aumenta improvvisamente. | Ciò è causato da transazioni a lunga esecuzione. Quando viene eseguito il commit di una transazione (una istruzione singola o più istruzioni) sull'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 attuale per calcolare il ritardo di replica. Di conseguenza, una transazione a lunga esecuzione
sull'origine comporterebbe un ritardo di replica immediato e di grandi dimensioni sulla
replica. Se il numero di modifiche alle righe nella transazione è elevato, l'esecuzione della replica impiegherà molto tempo. Nel frattempo, il ritardo di replica aumenta. Al termine della transazione della replica, 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:
|
La modifica dei flag di replica parallela genera un errore. | È stato impostato un valore errato per uno o più di questi flag.
Sull'istanza principale in cui è visualizzato il messaggio di errore, imposta i flag di replica parallela:
|
La creazione della replica non riesce a causa del timeout. | Le transazioni non impegnate a lunga esecuzione nell'istanza principale possono causare la mancata creazione della replica di lettura.
Ricrea la replica dopo aver arrestato 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 . |
L'origine potrebbe non essere più disponibile oppure il dump conteneva pacchetti troppo grandi.
Assicurati che la rete principale esterna sia disponibile per la connessione. Puoi anche modificare i valori dei flag net_read_timeout e net_write_timeout sull'istanza di origine per arrestare l'errore. Per maggiori informazioni sui valori consentiti per questi flag, consulta Configurare i flag di database. Per scoprire di più sull'utilizzo dei flag |
La migrazione iniziale dei dati è riuscita, ma nessun dato è stato replicato. | Una delle possibili cause principali potrebbe essere che il database di origine abbia definito flag di replica, il che impedisce la replica di alcune o tutte le modifiche al database.
Assicurati che i flag di replica come Esegui il comando |
La migrazione iniziale dei dati è riuscita, ma la replica dei dati smette di funzionare dopo un po' di tempo. | Tentativi da effettuare
|
mysqld check failed: data disk is full . |
Il disco dati dell'istanza di replica è pieno.
Aumenta la dimensione del disco dell'istanza di replica. Puoi aumentare manualmente le dimensioni del disco o abilitare l'aumento automatico dello spazio di archiviazione. |
Esamina i log di replica
Quando verifichi le impostazioni di replica, vengono generati i log.
Per visualizzare questi log:
Vai al visualizzatore log nella console Google Cloud.
- Seleziona la replica Cloud SQL dal menu a discesa Istanza.
- Seleziona il file di log
replication-setup.log
.
Se la replica Cloud SQL non riesce a connettersi al server esterno, conferma quanto segue:
- Qualsiasi firewall sul server esterno è configurato in modo da consentire le connessioni dall'indirizzo IP in uscita della replica Cloud SQL.
- La configurazione SSL/TLS è corretta.
- L'utente, l'host e la password di replica sono corretti.
Passaggi successivi
- Scopri di più sull'aggiornamento di un'istanza.
- Scopri di più sulla gestione delle repliche.
- Scopri di più sul monitoraggio delle istanze.
- Scopri di più sulla promozione della replica di Cloud SQL.