MariaDB
 sql >> Base de Dados >  >> RDS >> MariaDB

Migração de rede com tempo de inatividade zero com o MySQL Galera Cluster usando o nó de retransmissão


O provisionamento automático de nós do Galera Cluster simplifica a complexidade de dimensionar um cluster de banco de dados com consistência de dados garantida. SST e IST melhoram a usabilidade da sincronização inicial de dados sem a necessidade de fazer backup manual do banco de dados e copiá-lo para o novo nó. Combine isso com a capacidade do Galera de tolerar diferentes configurações de rede (por exemplo, replicação WAN), agora podemos migrar o banco de dados entre diferentes redes isoladas sem interrupção de serviço.

Nesta postagem do blog, veremos como migrar nosso MySQL Galera Cluster sem tempo de inatividade. Moveremos o banco de dados do Amazon Web Service (AWS) EC2 para o Google Cloud Platform (GCP) Compute Engine, com a ajuda de um nó de retransmissão. Observe que tivemos uma postagem de blog semelhante no passado, mas esta usa uma abordagem diferente.

O diagrama a seguir simplifica nosso plano de migração:

Preparação do local antigo


Como os dois sites não podem se comunicar entre si devido ao security group ou ao isolamento da VPC, precisamos ter um nó de retransmissão para unir esses dois sites. Este nó pode estar localizado em qualquer um dos sites, mas deve ser capaz de se conectar a um ou mais nós do outro lado na porta 3306 (MySQL), 4444 (SST), 4567 (gcomm) e 4568 (IST). Aqui está o que já temos e como escalaremos o site antigo:

Você também pode usar um nó Galera existente (por exemplo, o terceiro nó) como o nó de retransmissão, desde que tenha conectividade com o outro lado. A desvantagem é que a capacidade do cluster será reduzida para dois, porque um nó será usado para SST e retransmitindo o fluxo de replicação do Galera entre os sites. Dependendo do tamanho do conjunto de dados e da conexão entre os sites, isso pode apresentar problemas de confiabilidade do banco de dados no cluster atual.

Então, vamos usar um quarto nó, para reduzir o risco no cluster de produção atual ao sincronizar com o outro lado. Primeiro, crie uma nova instância no AWS Dashboard com um endereço IP público (para que possa se comunicar com o mundo externo) e permita as portas de comunicação Galera necessárias (TCP 3306, 4444, 4567-4568).

Implante o quarto nó (nó de retransmissão) no site antigo. Se você estiver usando o ClusterControl, você pode simplesmente usar o recurso "Add Node" para dimensionar o cluster (não se esqueça de configurar o SSH sem senha do nó ClusterControl para este quarto host com antecedência):

Certifique-se de que o nó de retransmissão esteja sincronizado com o cluster atual e possa se comunicar com o outro lado.

A partir do novo site, vamos nos conectar ao nó de retransmissão, pois este é o único nó que tem conectividade com o mundo exterior.

Nova implantação do site


No novo site, implantaremos uma configuração semelhante com um nó ClusterControl e um cluster Galera de três nós. Ambos os sites devem usar a mesma versão do MySQL. Aqui está nossa arquitetura no novo site:

Com o ClusterControl, a implantação do novo cluster está a apenas alguns cliques de distância e é um recurso gratuito na edição da comunidade. Vá para ClusterControl -> Deploy Database Cluster -> MySQL Galera e siga o assistente de implantação:

Clique em Deploy e monitore o progresso em Activity -> Jobs -> Create Cluster. Uma vez feito, você deve ter o seguinte no painel:

Neste ponto, você está tendo dois Clusters Galera separados - 4 nós no site antigo e 3 nós no novo site.

Conectando os dois sites


No novo site (GCP), escolha um nó para se comunicar com o nó de retransmissão no site antigo. Vamos escolher a galera-gcp1 como o conector para o nó de retransmissão (galera-aws4). O diagrama a seguir ilustra nosso plano de ponte:

As coisas importantes para configurar são os seguintes parâmetros:
  • wsrep_sst_donor :O wsrep_node_name do nódulo doador. Na galera-gcp1, defina o doador como galera-aws4.
  • wsrep_sst_auth :as credenciais do usuário SST no formato nome de usuário:senha devem seguir o site antigo (AWS).
  • wsrep_sst_receive_address :O endereço IP que receberá o SST no nó do joiner. Na galera-gcp1, defina isso como o endereço IP público deste nó.
  • wsrep_cluster_address :Cadeia de conexão Galera. Na galera-gcp1, adicione o endereço IP público da galera-aws4.
  • wsrep_provider_options :
    • gmcast.segment:o padrão é 0. Defina um número inteiro diferente em todos os nós no GCP.

  1. No nó de retransmissão (galera-aws4), recupere o wsrep_node_name:
    $ mysql -uroot -p -e 'SELECT @@wsrep_node_name'
    Enter password:
    +-------------------+
    | @@wsrep_node_name |
    +-------------------+
    | 10.0.0.13         |
    +-------------------+

  2. No my.cnf da galera-gcp1, defina wsrep_sst_donor valor para o wsrep_node_name do nó de retransmissão e wsrep_sst_receive_address para o endereço IP público da galera-gcp1:
    wsrep_sst_donor=10.0.0.13
    wsrep_sst_receive_address=35.197.136.232

  3. Em todos os nós no GCP, verifique se o wsrep_sst_auth o valor é idêntico seguindo o site antigo (AWS) e altere o segmento Galera para 1 (para que o Galera saiba que ambos os sites estão em redes diferentes):
    wsrep_sst_auth=backupuser:mysecretP4ssW0rd
    wsrep_provider_options="base_port=4567; gcache.size=512M; gmcast.segment=1"

  4. Na galera-gcp1, defina o wsrep_cluster_address para incluir o endereço IP público do nó de retransmissão:
    wsrep_cluster_address=gcomm://10.148.0.2,10.148.0.3,10.148.0.4,13.229.247.149

    **Modificar apenas wsrep_cluster_address na galera-gcp1. Não modifique este parâmetro na galera-gcp2 e na galera-gcp3.

  5. Interrompa todos os nós no GCP. Se você estiver usando o ClusterControl, vá para o menu suspenso Ações do cluster -> Parar cluster. Também é necessário desativar a recuperação automática nos níveis de cluster e nó, para que o ClusterControl não tente recuperar os nós com falha.

  6. Agora a parte de sincronização. Inicie galera-gcp1. Você pode ver no log de erros do MySQL no nó doador que o SST é iniciado entre o nó de retransmissão (10.0.0.13) usando um endereço público na galera-gcp1 (35.197.136.232):
    2017-12-19T13:58:04.765238Z 0 [Note] WSREP: Initiating SST/IST transfer on DONOR side (wsrep_sst_xtrabackup-v2 --role 'donor' --address '35.197.136.232:4444/xtrabackup_sst//1' --socket '/var/lib/mysql/m
    ysql.sock' --datadir '/var/lib/mysql/' --defaults-file '/etc/my.cnf' --defaults-group-suffix ''   '' --gtid 'df23adb8-b567-11e7-8c50-a386c8cc7711:151181')
    2017-12-19T13:58:04.765468Z 5 [Note] WSREP: DONOR thread signaled with 0
            2017-12-19T13:58:15.158757Z WSREP_SST: [INFO] Streaming the backup to joiner at 35.197.136.232 4444
    2017-12-19T13:58:52.512143Z 0 [Note] WSREP: 1.0 (10.0.0.13): State transfer to 0.0 (10.148.0.2) complete.

    Observe que, neste momento, a galera-gcp1 será inundada com as seguintes linhas:
    2017-12-19T13:32:47.111002Z 0 [Note] WSREP: (ed66842b, 'tcp://0.0.0.0:4567') connection to peer 00000000 with addr tcp://10.0.0.118:4567 timed out, no messages seen in PT3S
    2017-12-19T13:32:48.111123Z 0 [Note] WSREP: (ed66842b, 'tcp://0.0.0.0:4567') connection to peer 00000000 with addr tcp://10.0.0.90:4567 timed out, no messages seen in PT3S
    2017-12-19T13:32:50.611462Z 0 [Note] WSREP: (ed66842b, 'tcp://0.0.0.0:4567') connection to peer 00000000 with addr tcp://10.0.0.25:4567 timed out, no messages seen in PT3S

    Você pode ignorar esse aviso com segurança, pois a galera-gcp1 continua tentando ver os nós restantes além do nó de retransmissão na AWS.

  7. Depois que o SST no galera-gcp1 for concluído, o ClusterControl no GCE não poderá conectar os nós do banco de dados devido à falta de GRANTs (GRANTs existentes foram substituídos após a sincronização da AWS). Então, aqui está o que precisamos fazer depois que o SST for concluído na galera-gcp1:
    mysql> GRANT ALL PRIVILEGES ON *.* TO [email protected]'10.148.0.5' IDENTIFIED BY 'cmon' WITH GRANT OPTION;

    Feito isso, o ClusterControl informará corretamente o estado da galera-gcp1 conforme destacado abaixo:

  8. A última parte é iniciar a galera-gcp2 e a galera-gcp3 restantes, um nó por vez. Vá para ClusterControl -> Nós -> escolha o nó -> Iniciar nó. Depois que todos os nós estiverem sincronizados, você deverá obter 7 como o tamanho do cluster:

O cluster agora está operando em ambos os sites e a expansão está concluída.

Desativação


Depois que a migração for concluída e todos os nós estiverem sincronizados, você poderá começar a mudar seu aplicativo para o novo cluster no GCP:

Neste ponto, os dados do MySQL são replicados para todos os nós até o descomissionamento. O desempenho da replicação será tão bom quanto o nó mais distante do cluster permitir. O nó de retransmissão é crítico, pois transmite conjuntos de gravações para o outro lado. Do ponto de vista do aplicativo, é recomendável gravar em apenas um site por vez, o que significa que você terá que começar a redirecionar leituras/gravações da AWS e servi-las do cluster do GCP.

Para encerrar os nós de banco de dados antigos e mover para o cluster no GCP, precisamos realizar um desligamento normal (um nó por vez) na AWS. É importante encerrar os nós normalmente, pois o site da AWS contém a maioria dos nós (4/7) para este cluster. Desligá-los todos de uma vez fará com que o cluster no GCP entre no estado não primário, forçando o cluster a recusar a operação. Certifique-se de que o último nó a ser encerrado no lado da AWS seja o nó de retransmissão.

Não se esqueça de atualizar os seguintes parâmetros no galera-gcp1 de acordo:
  • wsrep_cluster_address - Remova o endereço IP público do nó de retransmissão.
  • wsrep_sst_donor - Comente esta linha. Deixe a Galera escolher automaticamente o doador.
  • wsrep_sst_receive_address - Comente esta linha. Deixe o Galera escolher automaticamente a interface de recebimento.

Seu Galera Cluster agora está sendo executado em uma plataforma, hosts e rede completamente novos sem um segundo de tempo de inatividade para seu serviço de banco de dados durante a migração. Quão legal é isso?