Usar uma importação personalizada para configurar a replicação de grandes bancos de dados externos

Esta página descreve o processo de configuração da replicação do servidor externo usando uma importação personalizada. Essas etapas são a melhor opção quando você precisa replicar de um banco de dados externo grande.

É necessário concluir todas as etapas nesta página. Quando terminar, você poderá administrar e monitorar a réplica da mesma forma que faria com qualquer outra instância do Cloud SQL.

Esse processo é compatível apenas com servidores externos configurados para usar replicação baseada em identificador de transação global (GTID, na sigla em inglês). Antes de iniciar a replicação, você precisa carregar dados do servidor externo na réplica do Cloud SQL. Se você não usar a replicação baseada em GTID, o Cloud SQL não poderá identificar a posição exata do registro binário para iniciar a replicação. Se não for possível usar a replicação baseada em GITD, configure a ferramenta de despejo para instituir um bloqueio somente leitura global durante o processo de despejo.

Antes de começar

Antes de começar, configure o servidor externo, crie a instância de representação de origem e configure o Cloud SQL réplica.

Atualizar permissões para o usuário da replicação

O usuário de replicação no servidor externo está configurado para aceitar conexões de qualquer host (%). Atualize essa conta de usuário para que ela seja usada somente com a réplica do Cloud SQL. Abra um terminal no servidor de banco de dados de origem e insira 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 você quer alterar.
USERNAME A conta do usuário de replicação no servidor externo.
GCP_USERNAME O nome de usuário da conta de usuário do GCP.
HOST O nome do host da conta de usuário do GCP.

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

Como as instâncias de réplica do Cloud SQL são somente leitura, para executar uma importação personalizada, você precisa promover a réplica do Cloud SQL para uma instância independente. Quando a importação de dados inicial estiver concluída, você rebaixará a instância de volta para uma réplica.

Executar um despejo e uma importação personalizados

Nesta seção, mostraremos como criar o arquivo dump e importá-lo para a réplica do Cloud SQL eventual usando utilitários do cliente mydumper ou mysqldump.

Ao despejar dados, talvez seja necessário excluir os bancos de dados genéricos do MySQL, incluindo mysql e sys, se eles existirem na instância de origem. Caso contrário, a importação de dados falhará. Consulte Como excluir (ou incluir) bancos de dados?.

Usar mydumper e myloader

Para criar um arquivo dump e importá-lo para o Cloud SQL:

  1. Crie um arquivo dump do banco de dados do servidor externo usando 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 usuário da replicação ou da conta de usuário no servidor externo que tem permissões de leitura do banco de dados.
    PASSWORD Senha do usuário de replicação.
    HOST O endereço IPv4 ou DNS do servidor externo.
  2. Importe os dados para a instância do Cloud SQL usando myloader.

     $ myloader -u REPLICA_USERNAME -p REPLICA_PASSWORD \
                --threads=16 \
                -d ./backup -h HOST -o
    Propriedade Descrição
    REPLICA_USERNAME A conta de usuário na instância do Cloud SQL.
    REPLICA_PASSWORD Senha do usuário 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 de dados. Você precisa dessas informações ao configurar a replicação com os procedimentos armazenados.

    Para receber as informações de GTID ou binlog do despejo de dados, execute o seguinte comando:

      sudo cat ./backup/metadata

Usar mysqldump

  1. Crie um dump usando 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 hospedado no Cloud SQL, isso será 3306.
    USERNAME O nome da conta de usuário da replicação ou da conta de usuário no servidor externo que tem permissões de leitura do banco de dados.
    USER_PASSWORD Senha do usuário de replicação.
    DATABASE_LIST Lista separada por espaço com todos os bancos de dados do servidor externo, exceto os bancos de dados do sistema (sys, mysql, performance_schema e information_schema). Use o comando SHOW DATABASES MySQL para listar seus bancos de dados.
    EXTERNAL_DATA Se o servidor externo não for compatível com GTID e você tiver permissão para acessar o bloqueio de leitura global nele, use --master-data=1. Caso contrário, não use essa propriedade.
    GTID_PURGED Se o servidor externo for compatível com GTID, use --set-gtid-purged=on; Caso contrário, não use essa propriedade.
    ADD_DROP_TABLE Se você quiser adicionar uma instrução DROP TABLE antes de cada instrução CREATE TABLE, inclua --add-drop-table.
    ROUTINES Se você quiser mostrar rotinas armazenadas, como procedimentos e funções, inclua --routines na saída de bancos de dados despejados.
    COMPRESS Se você quiser compactar todas as informações enviadas entre a réplica do Cloud SQL e o servidor externo, use --compress.
    GZIP Se você quiser compactar ainda mais o arquivo dump, use | gzip. Se o banco de dados tiver dados que não aceitam bem a compactação, como dados binários não compactáveis ou imagens JPG, não use isso.

    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 de dados. Você precisa dessas informações para configurar a replicação com os procedimentos armazenados do Cloud SQL.

    Para o GTID, procure uma linha semelhante a esta:

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

    No binlog, procure uma linha semelhante a esta:

       CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin-changelog.033877', MASTER_LOG_POS=360;
  3. Remova as seguintes linhas do arquivo dump que exigem super privilégios. Como os usuários do Cloud SQL não têm privilégios super, essas linhas fazem com que a importação falhe.

    Para a replicação baseada em GTID: remova a instrução SET GTID_PURGED junto com a instrução de configuração de variável de sessão no dump. 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 binlog, remova a instrução CHANGE MASTER. 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 usando a CLI mysql:

    mysql

    mysql -h REPLICA_HOST -u REPLICA_USER \
    -p REPLICA_DATABASE_NAME RESULT_FILE
    Propriedade Descrição
    REPLICA_HOST Host em que o servidor MySQL está localizado.
    REPLICA_USER Nome de usuário do MySQL a ser usado na conexão com o servidor.
    REPLICA_DATABASE_NAME Nome do banco de dados em que os dados estão localizados.
    RESULT_FILE Nome do arquivo dump a ser importado.

    exemplo

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

Também é possível importar o arquivo dump usando um bucket do Google Cloud. Consulte Como importar dados de um arquivo dump SQL para o Cloud SQL.

Rebaixar a instância do Cloud SQL

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

  1. Prepare um arquivo JSON de solicitação com o nome da instância que você quer rebaixar.

    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 de origem.

    exemplo

       {
         "demoteMasterContext": {
           "masterInstanceName": "cloudsql-source-instance",
           "skipReplicationSetup": true
         }
       }
  2. Abra um terminal e use os seguintes comandos para invocar 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 arquivo JSON.
    PROJECT_ID O ID do seu projeto no Google Cloud.
    INSTANCE-NAME O nome da instância a ser rebaixada.

    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 você precisa ver quando tiver terminado

Para garantir que suas instâncias foram configuradas corretamente, acesse a página Instâncias do Cloud SQL.

Você verá sua instância de representação de origem e a réplica do Cloud SQL. Elas são semelhantes a estas:

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

Iniciar replicação na instância do Cloud SQL

Nesta etapa, são usados procedimentos armazenados no Cloud SQL. Os procedimentos armazenados no Cloud SQL são instalados depois de chamar a solicitação demoteMaster. Elas são removidas depois de chamar promoteReplica. Para mais informações, consulte Procedimentos armazenados para o gerenciamento de replicação.

  1. Faça login na instância da réplica. Para mais informações, consulte Como se conectar usando um cliente de banco de dados de uma máquina local.
  2. Use o procedimento armazenado mysql.resetMaster para redefinir as configurações de replicação.

     mysql> call mysql.resetMaster();
  3. Configure a replicação. Esta etapa requer as informações de GTID ou binlog que você 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 do conjunto GTID a ser configurado.

    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 Endpoint de origem.
    PORT Porta de origem.
    USER_NAME Usuário de origem.
    USER_PASSWORD Senha do usuário de origem.
    MASTER_AUTO_POSITION Valor do parâmetro master_auto_position. Os valores possíveis são 0, 1.
    USE_SSL Se a replicação baseada em SSL será usada. Os valores possíveis são true, false. Se true, você precisará definir o campo caCertificate na solicitação DemoteMaster.
    USE_SSL_CLIENT_AUTH Indica se a autenticação do cliente SSL será usada. Os valores possíveis são true, false. Se true, você precisa definir os campos clientKey e clientCertificates na solicitação 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 Endpoint de origem.
    PORT Porta de origem.
    USER_NAME Usuário de origem.
    USER_PASSWORD Senha do usuário de origem.
    SOURCE_LOG_NAME O nome do registro binário na instância do banco de dados de origem que contém as informações de replicação.
    SOURCE_LOG_POS O local no registro binário mysql_binary_log_file_name em que a replicação começa a ler as informações de replicação.
    USE_SSL Se a replicação baseada em SSL será usada. Os valores possíveis são true, false. Se true, você precisará definir o campo caCertificate na solicitação DemoteMaster.
    USE_SSL_CLIENT_AUTH Indica se a autenticação do cliente SSL será usada. Os valores possíveis são true, false. Se true, você precisa definir os campos clientKey e clientCertificates na solicitação 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 do banco de dados externo.

       mysql> call mysql.startReplication();
  5. Verifique o status da replicação. Verifique se os campos Slave_IO_Running e Slave_SQL_Running estão dizendo YES.

       mysql> show slave status\G

    A saída deste comando é semelhante a:

       *************************** 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 a replicação

Depois de iniciar a replicação a partir do servidor externo, é necessário monitorar a replicação e concluir a migração. Para saber mais, consulte Como monitorar a replicação.

Resolver problemas

Problema Solução de problemas
Lost connection to MySQL server during query when dumping table. A origem pode ter ficado indisponível ou o dump continha pacotes muito grandes.

Verifique se a instância principal externa está disponível para conexão. Também é possível modificar os valores das sinalizações net_read_timeout e net_write_timeout na instância de origem para interromper o erro. Para mais informações sobre os valores permitidos para essas sinalizações, consulte Configurar sinalizações do banco de dados.

Para saber mais sobre como usar sinalizações mysqldump para migração de importação gerenciada, consulte Sinalizações de sincronização inicial permitidas e padrão

A migração inicial dos dados foi bem-sucedida, mas nenhum dado está sendo replicado. Uma possível causa raiz pode ser sinalizações de replicação definidas pelo banco de dados de origem, o que faz com que algumas ou todas as alterações do banco de dados não sejam replicadas.

Verifique se as sinalizações de replicação, como binlog-do-db, binlog-ignore-db, replicate-do-db ou replicate-ignore-db não estão definidas de maneira conflitante.

Execute o comando show master status na instância principal para ver as configurações atuais.

A migração inicial de dados foi bem-sucedida, mas a replicação de dados deixa de funcionar após um tempo. O que tentar

  • Verifique as métricas de replicação da instância de réplica na seção Cloud Monitoring do console do Google Cloud.
  • Os erros da linha de execução de E/S do MySQL ou do SQL podem ser encontrados no Cloud Logging nos arquivos mysql.err log.
  • O erro também pode ser encontrado ao se conectar à 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 de réplica. Aumente o tamanho do disco manualmente ou ative o aumento automático de armazenamento.

Analisar os registros de replicação

Ao verificar as configurações de replicação, os registros são gerados.

Para visualizar esses registros, siga estas etapas:

  1. Acesse o visualizador de registros no console do Google Cloud:

    Acessar o Visualizador de registros

  2. Selecione a réplica do Cloud SQL na lista suspensa Instância.
  3. Selecione o arquivo de registro replication-setup.log.

Se a réplica do Cloud SQL não conseguir se conectar ao servidor externo, confirme o seguinte:

  • Qualquer firewall no servidor do banco de dados de origem é configurado para permitir conexões usando o endereço IP de saída da réplica do Cloud SQL.
  • Sua configuração SSL/TLS está correta.
  • Seu usuário, host e senha de replicação estão corretos.

A seguir