Utilizzo di un'importazione personalizzata per configurare la replica da database esterni di grandi dimensioni

In questa pagina viene descritta la procedura per configurare la replica di server esterni mediante un'importazione personalizzata. Questi passaggi sono l'opzione migliore quando è necessario replicare da un grande database esterno.

Devi completare tutti i passaggi descritti in questa pagina. Al termine, puoi amministrare e monitorare la replica come faresti con qualsiasi altra istanza Cloud SQL.

Questo processo è supportato solo per i server esterni configurati per utilizzare la replica basata su GTID (Global Transaction Identifier). Prima di poter avviare la replica, devi caricare i dati dal server esterno nella replica Cloud SQL. Se non utilizzi la replica basata su GTID, Cloud SQL non è in grado di identificare la posizione esatta del log binario da cui iniziare la replica. Se non puoi utilizzare la replica basata su GITD, devi configurare lo strumento di dump in modo da istituire un blocco globale di sola lettura durante il processo di dump.

Prima di iniziare

Prima di iniziare, devi aver configurato il server esterno, creato l'istanza di rappresentazione di origine e impostato la replica Cloud SQL.

Aggiorna le autorizzazioni per l'utente di replica

L'utente di replica sul server esterno è configurato per accettare connessioni da qualsiasi host (%). Devi aggiornare questo account utente in modo che possa essere utilizzato solo con la replica Cloud SQL. Apri un terminale sul server del database di origine e inserisci questi comandi:

Client mysql

    UPDATE mysql.user
    SET Host='NEW_HOST' WHERE Host='OLD_HOST' AND User='USERNAME';
    GRANT REPLICATION SLAVE, EXECUTE 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 ON *.*
TO 'gcp_user'@'gmail.com';
FLUSH PRIVILEGES;
Proprietà Descrizione
NEW_HOST Specifica l'IP in uscita della replica Cloud SQL.
OLD_HOST Il valore attualmente assegnato a Host che vuoi modificare.
USERNAME L'account utente di replica sul server esterno.
GCP_USERNAME Il nome utente dell'account utente della piattaforma Google Cloud.
HOST Il nome host dell'account utente Google Cloud.

Configura la replica Cloud SQL come istanza principale

Poiché le istanze di replica Cloud SQL sono di sola lettura, per eseguire un'importazione personalizzata devi promuovere la replica Cloud SQL a un'istanza autonoma. Una volta completata l'importazione iniziale dei dati, fai retrocedere l'istanza a replica.

Esegui un dump personalizzato e un'importazione

In questa sezione, ti mostreremo come creare il file di dump e importarlo nell'eventuale replica Cloud SQL utilizzando mydumper o le utilità client di mysqldump.

Quando esegui il dump dei dati, potresti dover escludere i database generici MySQL, tra cui mysql e sys, se esistono nell'istanza di origine. In caso contrario, l'importazione dei dati non andrà a buon fine. Vedi Come escludere (o includere) i database?.

Utilizza mydumper e myloader

Per creare un file di dump e importarlo in Cloud SQL:

  1. Crea un file di dump del database del server esterno utilizzando mydumper.

       $ mydumper -u USERNAME -p PASSWORD \
                  --threads=16 -o ./backup \
                  -h HOST \
                  --no-locks \
                  --regex '^(?!(mysql\.|sys\.))'
    
    Proprietà Descrizione
    USERNAME Il nome dell'account utente o dell'account utente di replica sul server esterno con autorizzazioni di lettura del database.
    PASSWORD Password utente di replica.
    HOST L'indirizzo IPv4 o DNS del server esterno.
  2. Importa i dati nell'istanza Cloud SQL utilizzando myloader.

     $ myloader -u REPLICA_USERNAME -p REPLICA_PASSWORD \
                --threads=16 \
                -d ./backup -h HOST -o
    
    Proprietà Descrizione
    REPLICA_USERNAME L'account utente nell'istanza Cloud SQL.
    REPLICA_PASSWORD Password utente dell'istanza Cloud SQL.
    HOST L'IPv4 per l'istanza Cloud SQL.
  3. Annota le informazioni GTID o binlog del dump dei dati. Queste informazioni sono necessarie per configurare la replica con le stored procedure.

    Per ottenere le informazioni GTID o binlog del dump dei dati, esegui questo comando:

      sudo cat ./backup/metadata
    

Utilizza mysqldump

  1. Crea un dump utilizzando mysqldump:

    mysqldump

    mysqldump \
        --host=EXTERNAL_HOST \
        --port=EXTERNAL_PORT \
        --user=USERNAME\
        --password=PASSWORD \
        --databases=DATABASE_LIST  \
        --hex-blob \
        --master-data=EXTERNAL_DATA  \
        --no-autocommit \
        --default-character-set=utf8mb4 \
        --single-transaction \
        GTID_PURGED \
        ADD_DROP_TABLE \
        ROUTINES \
        COMPRESS \
        GZIP
    
    Proprietà Descrizione
    EXTERNAL_HOST L'indirizzo IPv4 o DNS del server esterno.
    EXTERNAL_PORT La porta del server esterno. Se il server esterno è ospitato su Cloud SQL, il valore è 3306.
    USERNAME Il nome dell'account utente o dell'account utente di replica sul server esterno con autorizzazioni di lettura del database.
    USER_PASSWORD Password utente di replica.
    DATABASE_LIST Elenco separato da spazi di tutti i database sul server esterno, ad eccezione dei database di sistema (sys, mysql, performance_schema e information_schema). Utilizza il comando SHOW DATABASES MySQL per elencare i database.
    EXTERNAL_DATA Se il tuo server esterno non supporta GTID e disponi dell'autorizzazione per accedere al blocco di lettura globale sul server, utilizza --master-data=1. In caso contrario, non utilizzare questa proprietà.
    GTID_PURGED Se il tuo server esterno supporta GTID, usa --set-gtid-purged=on. In caso contrario, non utilizzare questa proprietà.
    ADD_DROP_TABLE Se vuoi aggiungere un'istruzione DROP TABLE prima di ogni istruzione CREATE TABLE, includi --add-drop-table.
    ROUTINES Se vuoi mostrare le routine archiviate, come procedure e funzioni, nell'output dei database sottoposti a dump, includi --routines.
    COMPRESS Se vuoi comprimere tutte le informazioni scambiate tra la replica Cloud SQL e il server esterno, utilizza --compress.
    GZIP Se vuoi comprimere ulteriormente il file di dump, utilizza | gzip. Non utilizzare questo tipo di dati se il database contiene dati che non vengono compressi correttamente, ad esempio dati binari incomprimibili o immagini JPG.

    esempio

    
    mysqldump \
        --host=192.0.2.1 \
        --port=3306 \
        --user=replicationUser \
        --password \
        --databases guestbook journal \
        --hex-blob \
        --master-data=1 \
        --no-autocommit \
        --default-character-set=utf8mb4 \
        --single-transaction \
        --compress \
        | gzip
    
  2. Annota le informazioni GTID o binlog del dump dei dati. Queste informazioni sono necessarie per configurare la replica con le procedure archiviate di Cloud SQL.

    Per il codice GTID, cerca una riga simile alla seguente:

       SET @@GLOBAL.GTID_PURGED='32eb1e6a-17b6-11ea-a39e-06d94ac3ec98:1-33496';
    

    Per il binlog, cerca una riga simile alla seguente:

       CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.033877', MASTER_LOG_POS=360;
    
  3. Rimuovi le righe seguenti dal file di dump che richiedono privilegi superflui. Poiché gli utenti di Cloud SQL non dispongono di super privilegi, queste righe impediscono l'importazione.

    Per la replica basata su GTID: rimuovi l'istruzione SET GTID_PURGED insieme all'istruzione di impostazione della variabile di sessione nel dump. Ad esempio:

       ...
       SET @MYSQLDUMP_TEMP_LOG_BIN = @@SESSION.SQL_LOG_BIN;
       SET @@SESSION.SQL_LOG_BIN= 0;
       ...
       SET @@GLOBAL.GTID_PURGED='32eb1e6a-17b6-11ea-a39e-06d94ac3ec98:1-33496';
       ...
       SET @@SESSION.SQL_LOG_BIN=@MYSQLDUMP_TEMP_LOG_BIN;
    

    Per la replica basata su binlog, rimuovi l'istruzione CHANGE MASTER. Ad esempio:

       ...
       CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.033877', MASTER_LOG_POS=360;
        ...
    
  4. Importa i dati nella replica Cloud SQL utilizzando l'interfaccia a riga di comando mysql:

    mysql

    mysql -h REPLICA_HOST -u REPLICA_USER \
    -p REPLICA_DATABASE_NAME RESULT_FILE
    
    Proprietà Descrizione
    REPLICA_HOST Host su cui si trova il server MySQL.
    REPLICA_USER Nome utente MySQL da usare per la connessione al server.
    REPLICA_DATABASE_NAME Nome del database in cui si trovano i dati.
    RESULT_FILE Nome del file di dump da importare.

    esempio

      mysql -h 255.255.255.255 -u replica_username -p replica_db < result.sql
    

Puoi anche importare il file di dump utilizzando un bucket Google Cloud. Consulta Importazione di dati da un file di dump SQL in Cloud SQL.

Retrocedi l'istanza Cloud SQL

Per retrocedere l'istanza Cloud SQL a una replica Cloud SQL, utilizza il metodo demoteMaster sull'istanza.

  1. Prepara un file JSON di richiesta con il nome dell'istanza che vuoi far retrocedere.

    JSON di origine

     {
        "demoteMasterContext": {
          "masterInstanceName": SOURCE_REPRESENTATION_INSTANCE_NAME,
          "skipReplicationSetup": true
          }
     }
    
    Proprietà Descrizione
    SOURCE_REPRESENTATION_INSTANCE_NAME Il nome dell'istanza di rappresentazione sorgente.

    esempio

       {
         "demoteMasterContext": {
           "masterInstanceName": "cloudsql-source-instance",
           "skipReplicationSetup": true
         }
       }
    
  2. Apri un terminale e utilizza i seguenti comandi per richiamare demoteMaster:

    arricciare

      gcloud auth login
      ACCESS_TOKEN="$(gcloud auth print-access-token)"
      curl --header "Authorization: Bearer ${ACCESS_TOKEN}" \
        --header 'Content-Type: application/json' \
        --data @JSON_PATH \
        -X POST \
      https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT-ID/instances/INSTANCE-NAME/demoteMaster
    
    Proprietà Descrizione
    JSON_PATH Il percorso del file JSON.
    PROJECT_ID L'ID del tuo progetto in Google Cloud.
    INSTANCE-NAME Il nome dell'istanza da retrocedere.

    esempio

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

Cosa dovresti vedere al termine

Per assicurarti che le istanze siano state configurate correttamente, vai alla pagina Istanze Cloud SQL.

Dovresti vedere l'istanza di rappresentazione di origine e la replica Cloud SQL. Sono simili alle seguenti:

ID istanza Tipo IP pubblico
(-) rappresentazione-sorgente-istanza MySQL principale esterno 10.68.48.3:3306
istanza-replica Replica di lettura MySQL 34.66.48.59

Avvia la replica sull'istanza Cloud SQL

Questo passaggio utilizza le stored procedure di Cloud SQL. Le procedure archiviate di Cloud SQL vengono installate dopo la chiamata della richiesta demoteMaster. Vengono rimossi dopo aver chiamato promoteReplica. Per maggiori informazioni, consulta Procedure archiviate per la gestione della replica.

  1. Accedi all'istanza di replica. Per maggiori informazioni, consulta Connessione tramite un client di database da una macchina locale.
  2. Utilizza la stored procedure di mysql.resetMaster per reimpostare le impostazioni di replica.

     mysql> call mysql.resetMaster();
    
  3. Configura la replica. Questo passaggio richiede le informazioni GTID o binlog che hai annotato in precedenza.

    GTID

    1. Configura il campo gtid_purged con la stored procedure mysql.skipTransactionWithGtid(GTID_TO_SKIP).
    Proprietà Descrizione
    GTID_TO_SKIP Il valore set GTID da configurare.

    Ad esempio:

        mysql> call mysql.skipTransactionWithGtid('32eb1e6a-17b6-11ea-a39e-06d94ac3ec98:1-33496');
    

    1. Esegui la stored procedure di mysql.setupExternalSourceAutoPosition(HOST, PORT, USER_NAME, USER_PASSWORD, MASTER_AUTO_POSITION, USE_SSL, USE_SSL_CLIENT_AUTH).
    Proprietà Descrizione
    HOST Endpoint di origine.
    PORT Porta di origine.
    USER_NAME Utente di origine.
    USER_PASSWORD Password utente di origine.
    MASTER_AUTO_POSITION Valore del parametro master_auto_position. I valori possibili sono 0 e 1.
    USE_SSL Indica se utilizzare la replica basata su SSL. I valori possibili sono true e false. Se true, devi impostare il campo caCertificate nella richiesta DemoteMaster.
    USE_SSL_CLIENT_AUTH Se utilizzare l'autenticazione client SSL. I valori possibili sono true e false. Se true, devi impostare i campi clientKey e clientCertificates nella richiesta demoteMaster.
        mysql> call mysql.setupExternalSourceAutoPosition('1.1.1.1', 3306, \
        'USERNAME', 'PASSWORD', \
        /* master_auto_position= */ 1,false, false); \
    

    binlog

    Esegui la stored procedure di mysql.setupExternalSource(HOST, PORT, USER_NAME, USER_PASSWORD, SOURCE_LOG_NAME, SOURCE_LOG_POS, USE_SSL, USE_SSL_CLIENT_AUTH).

    Proprietà Descrizione
    HOST Endpoint di origine.
    PORT Porta di origine.
    USER_NAME Utente di origine.
    USER_PASSWORD Password utente di origine.
    SOURCE_LOG_NAME Il nome del log binario nell'istanza del database di origine che contiene le informazioni sulla replica.
    SOURCE_LOG_POS La posizione nel log binario mysql_binary_log_file_name da cui la replica avvia la lettura delle informazioni di replica.
    USE_SSL Indica se utilizzare la replica basata su SSL. I valori possibili sono true e false. Se true, devi impostare il campo caCertificate nella richiesta DemoteMaster.
    USE_SSL_CLIENT_AUTH Se utilizzare l'autenticazione client SSL. I valori possibili sono true e false. Se true, devi impostare i campi clientKey e clientCertificates nella richiesta demoteMaster.
        mysql> call mysql.setupExternalSource('1.1.1.1', 3306, \
        'user_name', 'password', 'mysql-bin-changelog.033877', 360, \
        false, false);
    
  4. Utilizza la stored procedure mysql.startReplication() per avviare la replica dal database esterno.

       mysql> call mysql.startReplication();
    
  5. Verifica lo stato della replica. Assicurati che entrambi i campi Slave_IO_Running e Slave_SQL_Running indichino YES.

       mysql> show slave status\G
    

    L'output di questo comando è simile al seguente:

       *************************** 1. row ***************************
                       Slave_IO_State: Waiting for master to send event
                          Master_Host: 1.1.1.1
                          Master_User: user_name
                          Master_Port: 3306
                        Connect_Retry: 60
                      Master_Log_File: mysql-bin-changelog.000001
                  Read_Master_Log_Pos: 1
                       Relay_Log_File: relay-log.000002
                        Relay_Log_Pos: 1
                Relay_Master_Log_File: mysql-bin-changelog.000001
                     Slave_IO_Running: Yes
                    Slave_SQL_Running: Yes
                      Replicate_Do_DB:
                  Replicate_Ignore_DB:
                   Replicate_Do_Table:
               Replicate_Ignore_Table:
              Replicate_Wild_Do_Table:
          Replicate_Wild_Ignore_Table: mysql.%
                           Last_Errno: 0
                           Last_Error:
                         Skip_Counter: 0
                  Exec_Master_Log_Pos: 412
                      Relay_Log_Space: 752
                      Until_Condition: None
                       Until_Log_File:
                        Until_Log_Pos: 0
                   Master_SSL_Allowed: No
                   Master_SSL_CA_File:
                   Master_SSL_CA_Path:
                      Master_SSL_Cert:
                    Master_SSL_Cipher:
                       Master_SSL_Key:
                Seconds_Behind_Master: 0
        Master_SSL_Verify_Server_Cert: No
                        Last_IO_Errno: 0
                        Last_IO_Error:
                       Last_SQL_Errno: 0
                       Last_SQL_Error:
          Replicate_Ignore_Server_Ids:
                     Master_Server_Id: 1509941531
                          Master_UUID: 1cb2c80e-90f0-11eb-9ea3-02389b1c2e6f
                 Master_Info_File: mysql.slave_master_info
                        SQL_Delay: 0
              SQL_Remaining_Delay: NULL
          Slave_SQL_Running_State: Slave has read all r
               Master_Retry_Count: 86400
                      Master_Bind:
          Last_IO_Error_Timestamp:
         Last_SQL_Error_Timestamp:
                   Master_SSL_Crl:
               Master_SSL_Crlpath:
               Retrieved_Gtid_Set:
                Executed_Gtid_Set: 478af53c-bd24-11eb-be72-42010a80002a:1-226
                    Auto_Position: 0
       1 row in set (0.00 sec)
    

Procedi con la replica

Una volta avviata la replica dal server esterno, devi monitorare la replica e quindi completare la migrazione. Per scoprire di più, consulta Monitoraggio della replica.

Risolvere i problemi

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 sia disponibile la rete principale esterna 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 mysqldump per la migrazione dell'importazione gestita, consulta Flag di sincronizzazione iniziale consentiti e predefiniti

La migrazione iniziale dei dati è riuscita, ma non è stato possibile replicare alcun dato. Una possibile causa principale potrebbe essere che il database di origine ha definito flag di replica, il che impedisce la replica di alcune o 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 conflitto.

Esegui il comando show master status sull'istanza principale per visualizzare le impostazioni attuali.

La migrazione iniziale dei dati è riuscita, 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 di I/O MySQL o del thread SQL sono disponibili in Cloud Logging nei file mysql.err log.
  • L'errore si trova 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 abilitare l'aumento automatico dello spazio di archiviazione.

Esamina i log di replica

Quando verifichi le impostazioni di replica, vengono prodotti log.

Per visualizzare questi log:

  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 è in grado di 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