Use uma importação personalizada para configurar a replicação a partir de grandes bases de dados externas

MySQL   |  PostgreSQL   |  SQL Server

Esta página descreve o processo de configuração da replicação do servidor externo através de uma importação personalizada. Estes passos são a melhor opção quando precisa de replicar a partir de uma grande base de dados externa.

Tem de concluir todos os passos nesta página. Quando terminar, pode administrar e monitorizar a réplica da mesma forma que faria com qualquer outra instância do Cloud SQL.

Este processo só é suportado para servidores externos configurados para usar a replicação baseada no identificador global de transações (GTID). Antes de poder iniciar a replicação, tem de carregar dados do servidor externo para a réplica do Cloud SQL. Se não usar a replicação baseada em GTID, o Cloud SQL não consegue identificar a posição exata do registo binário a partir da qual iniciar a replicação. Se não puder usar a replicação baseada em GITD, tem de configurar a ferramenta de descarga para instituir um bloqueio global só de leitura durante o processo de descarga.

A replicação de GTID não é suportada para determinadas versões do Amazon RDS, do Amazon Aurora 5.6 e das versões iniciais do Amazon Aurora 5.7.

Antes de começar

Antes de começar, deve ter configurado o servidor externo, criado a instância de representação de origem e configurado a réplica do Cloud SQL.

Atualize as autorizações do utilizador de replicação

O utilizador da replicação no servidor externo está configurado para aceitar ligações de qualquer anfitrião (%). Deve atualizar esta conta de utilizador para que só possa ser usada com a réplica do Cloud SQL. Abra um terminal no servidor da base de dados de origem e introduza estes comandos:

Cliente 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;

exemplo

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;

Propriedade	Descrição
NEW_HOST	Especifique o IP de saída da réplica do Cloud SQL.
OLD_HOST	O valor atual atribuído a Host que quer alterar.
USERNAME	A conta de utilizador de replicação no servidor externo.
GCP_USERNAME	O nome de utilizador da conta de utilizador da GCP.
HOST	O nome do anfitrião da conta de utilizador da GCP.

Configure a réplica do Cloud SQL como uma instância principal

Uma vez que as instâncias de réplica do Cloud SQL são apenas de leitura, para fazer uma importação personalizada, tem de promover a réplica do Cloud SQL para uma instância autónoma. Quando a importação de dados inicial estiver concluída, rebaixe a instância para uma réplica.

Faça uma descarga e uma importação personalizadas

Nesta secção, mostramos-lhe como criar o ficheiro de despejo e importá-lo para a réplica do Cloud SQL final através de mydumper ou das utilidades do cliente mysqldump.

Quando exporta os dados, pode ter de excluir as bases de dados genéricas do MySQL, incluindo mysql e sys, se existirem na instância de origem. Caso contrário, a importação de dados falha. Consulte o artigo Como excluir (ou incluir) bases de dados?.

Use mydumper e myloader

Para criar um ficheiro de despejo e importá-lo para o Cloud SQL:

1. Crie um ficheiro de despejo da base de dados do servidor externo através de mydumper.

      $ mydumper -u USERNAME -p PASSWORD \
                 --threads=16 -o ./backup \
                 -h HOST \
                 --no-locks \
                 --regex '^(?!(mysql\.|sys\.))'

   Propriedade	Descrição
   USERNAME	O nome da conta de utilizador de replicação ou da conta de utilizador no servidor externo que tem autorizações de leitura da base de dados.
   PASSWORD	Palavra-passe do utilizador de replicação.
   HOST	O endereço IPv4 ou DNS do servidor externo.

2. Importe os dados para a instância do Cloud SQL através do myloader.

    $ myloader -u REPLICA_USERNAME -p REPLICA_PASSWORD \
               --threads=16 \
               -d ./backup -h HOST -o

   Propriedade	Descrição
   REPLICA_USERNAME	A conta de utilizador na instância do Cloud SQL.
   REPLICA_PASSWORD	Palavra-passe do utilizador da instância do Cloud SQL.
   HOST	O IPv4 da instância do Cloud SQL.

3. Anote as informações do GTID ou do binlog da descarga de dados. Precisa destas informações quando configurar a replicação com os procedimentos armazenados.

   Para obter o GTID ou as informações do binlog da descarga de dados, execute o seguinte comando:

     sudo cat ./backup/metadata

Usar mysqldump

1. Crie um despejo com 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

   Propriedade	Descrição
   EXTERNAL_HOST	O endereço IPv4 ou DNS do servidor externo.
   EXTERNAL_PORT	A porta do servidor externo. Se o servidor externo estiver alojado no Cloud SQL, esta é 3306.
   USERNAME	O nome da conta de utilizador de replicação ou da conta de utilizador no servidor externo que tem autorizações de leitura da base de dados.
   USER_PASSWORD	Palavra-passe do utilizador de replicação.
   DATABASE_LIST	Lista separada por espaços de todas as bases de dados no servidor externo, exceto as bases de dados do sistema (sys,mysql, performance_schema e information_schema). Use o comando SHOW DATABASES do MySQL para listar as suas bases de dados.
   EXTERNAL_DATA	Se o seu servidor externo não suportar o GTID e tiver autorização para aceder ao bloqueio de leitura global, use --master-data=1. Caso contrário, não use esta propriedade.
   GTID_PURGED	Se o seu servidor externo suportar GTID, use --set-gtid-purged=on; caso contrário, não use esta propriedade.
   ADD_DROP_TABLE	Se quiser adicionar uma declaração DROP TABLE antes de cada declaração CREATE TABLE, inclua --add-drop-table.
   ROUTINES	Se quiser mostrar rotinas armazenadas, como procedimentos e funções, na saída de bases de dados transferidas, inclua --routines.
   COMPRESS	Se quiser comprimir todas as informações enviadas entre a réplica do Cloud SQL e o servidor externo, use --compress.
   GZIP	Se quiser comprimir ainda mais o ficheiro de despejo, use | gzip. Se a sua base de dados contiver dados que não são bem comprimidos, como dados binários não comprimíveis ou imagens JPG, não use esta opção.

   exemplo

   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. Anote as informações do GTID ou do binlog da descarga de dados. Precisa destas informações para configurar a replicação com os procedimentos armazenados do Cloud SQL.

   Para o GTID, procure uma linha semelhante à seguinte:

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

   Para o binlog, procure uma linha semelhante à seguinte:

      CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.033877', MASTER_LOG_POS=360;

3. Remova as seguintes linhas no ficheiro de despejo que requerem privilégios de superutilizador. Uma vez que os utilizadores do Cloud SQL não têm superprivilégios, estas linhas fazem com que a importação falhe.

   Para a replicação baseada em GTID: remova a declaração SET GTID_PURGED juntamente com a declaração de definição da variável de sessão no despejo. Por exemplo:

      ...
      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;

   Para a replicação baseada em binlogs, remova a declaração CHANGE MASTER. Por exemplo:

      ...
      CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.033877', MASTER_LOG_POS=360;
       ...

4. Importe os dados para a réplica do Cloud SQL através da CLI mysql:

   mysql

   mysql -h REPLICA_HOST -u REPLICA_USER \
   -p REPLICA_DATABASE_NAME RESULT_FILE

   Propriedade	Descrição
   REPLICA_HOST	Anfitrião no qual o servidor MySQL está localizado.
   REPLICA_USER	Nome de utilizador do MySQL a usar ao estabelecer ligação ao servidor.
   REPLICA_DATABASE_NAME	Nome da base de dados onde os dados estão localizados.
   RESULT_FILE	Nome do ficheiro de despejo a importar.

   exemplo

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

Também pode importar o ficheiro de despejo através de um Google Cloud contentor. Consulte o artigo Importar dados de um ficheiro de captura SQL para o Cloud SQL.

Rebaixar a instância do Cloud SQL

Para despromover a instância do Cloud SQL para uma réplica do Cloud SQL, use o método demoteMaster na instância.

1. Prepare um ficheiro JSON de pedido com o nome da instância que quer despromover.

   JSON de origem

    {
       "demoteMasterContext": {
         "masterInstanceName": SOURCE_REPRESENTATION_INSTANCE_NAME,
         "skipReplicationSetup": true
         }
    }

   Propriedade	Descrição
   SOURCE_REPRESENTATION_INSTANCE_NAME	O nome da instância de representação da origem.

   exemplo

      {
        "demoteMasterContext": {
          "masterInstanceName": "cloudsql-source-instance",
          "skipReplicationSetup": true
        }
      }

2. Abra um terminal e use os seguintes comandos para invocar o demoteMaster:

   curl

     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

   Propriedade	Descrição
   JSON_PATH	O caminho para o ficheiro JSON.
   PROJECT_ID	O ID do seu projeto em Google Cloud.
   INSTANCE-NAME	O nome da instância a despromover.

   exemplo

      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

O que deve ver quando terminar

Para garantir que as instâncias foram configuradas corretamente, aceda à página de instâncias do Cloud SQL.

Deve ver a instância de representação de origem e a réplica do Cloud SQL. Têm um aspeto semelhante ao seguinte:

ID da instância	Tipo	IP público
(-) source-representation-instance	MySQL externo principal	10.68.48.3:3306
replica-instance	Réplica de leitura do MySQL	34.66.48.59

Inicie a replicação na instância do Cloud SQL

Nota: os endereços IP devem ser preservados nos passos Promover ou Rebaixar. Se outra operação ocorrer entre os passos, o endereço IP da instância do Cloud SQL pode mudar. Se a replicação estiver danificada devido a um problema de conetividade, verifique os endereços IP de saída e certifique-se de que os endereços IP adequados estão na lista de autorizações na origem externa.

Este passo usa procedimentos armazenados do Cloud SQL. Os procedimentos armazenados do Cloud SQL são instalados após chamar o pedido demoteMaster. São removidos após a chamada promoteReplica. Para mais informações, consulte o artigo Procedimentos armazenados para gestão da replicação.

1. Inicie sessão na instância de réplica. Para mais informações, consulte o artigo Estabelecer ligação através de um cliente de base de dados a partir de um computador local.

2. Use o procedimento armazenado mysql.resetMaster para repor as definições de replicação.

    mysql> call mysql.resetMaster();

3. Configure a replicação. Este passo requer as informações do GTID ou binlog que anotou anteriormente.

   GTID

   1. Configure o campo gtid_purged com o procedimento armazenado mysql.skipTransactionWithGtid(GTID_TO_SKIP).

   Propriedade	Descrição
   GTID_TO_SKIP	O valor GTID set a configurar.

   Por exemplo:

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

   1. Execute o procedimento armazenado mysql.setupExternalSourceAutoPosition(HOST, PORT, USER_NAME, USER_PASSWORD, MASTER_AUTO_POSITION, USE_SSL, USE_SSL_CLIENT_AUTH).

   Propriedade	Descrição
   HOST	Ponto final de origem.
   PORT	Porta de origem.
   USER_NAME	Utilizador de origem.
   USER_PASSWORD	Palavra-passe do utilizador de origem.
   MASTER_AUTO_POSITION	Valor do parâmetro master_auto_position. Os valores possíveis são 0 e 1.
   USE_SSL	Se a replicação baseada em SSL deve ser usada. Os valores possíveis são true e false. Se true, tem de definir o campo caCertificate no pedido DemoteMaster.
   USE_SSL_CLIENT_AUTH	Se deve usar a autenticação de cliente SSL. Os valores possíveis são true e false. Se true, tem de definir os campos clientKey e clientCertificates no pedido demoteMaster.

       mysql> call mysql.setupExternalSourceAutoPosition('1.1.1.1', 3306, \
       'USERNAME', 'PASSWORD', \
       /* master_auto_position= */ 1,false, false); \

   binlog

   Execute o procedimento armazenado mysql.setupExternalSource(HOST, PORT, USER_NAME, USER_PASSWORD, SOURCE_LOG_NAME, SOURCE_LOG_POS, USE_SSL, USE_SSL_CLIENT_AUTH).

   Propriedade	Descrição
   HOST	Ponto final de origem.
   PORT	Porta de origem.
   USER_NAME	Utilizador de origem.
   USER_PASSWORD	Palavra-passe do utilizador de origem.
   SOURCE_LOG_NAME	O nome do registo binário na instância da base de dados de origem que contém as informações de replicação.
   SOURCE_LOG_POS	A localização no registo mysql_binary_log_file_name binário em que a replicação começa a ler as informações de replicação.
   USE_SSL	Se a replicação baseada em SSL deve ser usada. Os valores possíveis são true e false. Se true, tem de definir o campo caCertificate no pedido DemoteMaster.
   USE_SSL_CLIENT_AUTH	Se deve usar a autenticação de cliente SSL. Os valores possíveis são true e false. Se true, tem de definir os campos clientKey e clientCertificates no pedido demoteMaster.

       mysql> call mysql.setupExternalSource('1.1.1.1', 3306, \
       'user_name', 'password', 'mysql-bin-changelog.033877', 360, \
       false, false);

4. Use o procedimento armazenado mysql.startReplication() para iniciar a replicação a partir da base de dados externa.

      mysql> call mysql.startReplication();

5. Valide o estado da replicação. Certifique-se de que os campos Slave_IO_Running e Slave_SQL_Running indicam YES.

      mysql> show slave status\G

   O resultado deste comando tem um aspeto semelhante ao seguinte:

      *************************** 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)

Continuar com a replicação

Depois de iniciar a replicação a partir do servidor externo, tem de monitorizar a replicação e, em seguida, concluir a migração. Para saber mais, consulte o artigo Monitorizar a replicação.

Resolver problemas

Problema	Resolução de problemas
Lost connection to MySQL server during query when dumping table.	A origem pode ter ficado indisponível ou o despejo continha pacotes demasiado grandes. Certifique-se de que o dispositivo principal externo está disponível para ligação. Também pode modificar os valores das flags net_read_timeout e net_write_timeout na instância de origem para parar o erro. Para mais informações sobre os valores permitidos para estas flags, consulte o artigo Configure flags da base de dados. Para saber mais sobre a utilização de flags mysqldumppara a migração de importações geridas, consulte o artigo Flags de sincronização inicial permitidas e predefinidas
A migração de dados inicial foi bem-sucedida, mas não está a ser feita a replicação de dados.	Uma possível causa principal pode ser a base de dados de origem ter definido flags de replicação que resultam na não replicação de algumas ou todas as alterações da base de dados. Certifique-se de que as flags de replicação, como binlog-do-db, binlog-ignore-db, replicate-do-db ou replicate-ignore-db, não estão definidas de forma conflituosa. Execute o comando show master status na instância principal para ver as definições atuais.
A migração de dados inicial foi bem-sucedida, mas a replicação de dados deixa de funcionar após algum tempo.	Opções que pode testar: Verifique as métricas de replicação da instância da réplica na secção do Cloud Monitoring da Google Cloud consola. Pode encontrar os erros do thread de E/S do MySQL ou do thread SQL em Cloud Logging nos ficheiros mysql.err log. O erro também pode ser encontrado quando se liga à instância da réplica. Execute o comando SHOW SLAVE STATUS e verifique os seguintes campos na saída: Slave_IO_Running Slave_SQL_Running Last_IO_Error Last_SQL_Error
mysqld check failed: data disk is full.	O disco de dados da instância da réplica está cheio. Aumente o tamanho do disco da instância da réplica. Pode aumentar manualmente o tamanho do disco ou ativar o aumento automático do armazenamento.

Reveja os registos de replicação

Quando valida as definições de replicação, são gerados registos.

Pode ver estes registos através dos seguintes passos:

1. Aceda ao visualizador de registos na Google Cloud consola.

   Aceda ao visualizador de registos

2. Selecione a réplica do Cloud SQL no menu pendente Instância.
3. Selecione o ficheiro de registo replication-setup.log.

Se a réplica do Cloud SQL não conseguir estabelecer ligação ao servidor externo, confirme o seguinte:

• Qualquer firewall no servidor externo está configurada para permitir ligações a partir do endereço IP de saída da réplica do Cloud SQL.
• A sua configuração SSL/TLS está correta.
• O utilizador, o anfitrião e a palavra-passe da replicação estão corretos.

O que se segue?

• Saiba como atualizar uma instância.
• Saiba como gerir réplicas.
• Saiba mais sobre a monitorização de instâncias.
• Saiba como promover a sua réplica do Cloud SQL para promover a réplica a uma instância autónoma e parar a replicação a partir do servidor externo.