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

Criando um Hot Standby na Amazon AWS usando o MariaDB Cluster

O Galera Cluster 4.0 foi lançado pela primeira vez como parte do MariaDB 10.4 e há muitas melhorias significativas nesta versão. O recurso mais impressionante desta versão é a Replicação de Streaming, projetada para lidar com os seguintes problemas.

  • Problemas com transações longas
  • Problemas com grandes transações
  • Problemas com pontos de acesso em tabelas

Em um blog anterior, nos aprofundamos no novo recurso Streaming Replication em um blog em série de duas partes (Parte 1 e Parte 2). Parte deste novo recurso do Galera 4.0 são as novas tabelas de sistema que são muito úteis para consultar e verificar os nós do Galera Cluster e também os logs que foram processados ​​no Streaming Replication.

Também em blogs anteriores, também mostramos a maneira fácil de implantar um MySQL Galera Cluster na AWS e também como implantar um MySQL Galera Cluster 4.0 no Amazon AWS EC2.

A Percona ainda não lançou um GA para seu Percona XtraDB Cluster (PXC) 8.0, pois alguns recursos ainda estão em desenvolvimento, como a função wsrep do MySQL WSREP_SYNC_WAIT_UPTO_GTID que parece não estar presente ainda (pelo menos na versão PXC 8.0.15-5-27dev.4.2). No entanto, quando o PXC 8.0 for lançado, ele estará repleto de ótimos recursos, como...

  • Cluster resiliente aprimorado
  • Cluster amigável para nuvem
  • embalagem melhorada
  • Suporte de criptografia
  • DDL atômico

Enquanto aguardamos o lançamento do PXC 8.0 GA, abordaremos neste blog como você pode criar um Hot Standby Node no Amazon AWS para Galera Cluster 4.0 usando MariaDB.

O que é Hot Standby?

Hot standby é um termo comum em computação, especialmente em sistemas altamente distribuídos. É um método de redundância no qual um sistema é executado simultaneamente com um sistema primário idêntico. Quando ocorre uma falha no nó primário, o hot standby assume imediatamente a substituição do sistema primário. Os dados são espelhados para ambos os sistemas em tempo real.

Para sistemas de banco de dados, um servidor hot standby geralmente é o segundo nó após o mestre primário que está sendo executado em recursos poderosos (o mesmo que o mestre). Este nó secundário deve ser tão estável quanto o mestre primário para funcionar corretamente.

Ele também serve como um nó de recuperação de dados se o nó mestre ou o cluster inteiro ficar inativo. O nó de espera ativa substituirá o nó ou cluster com falha enquanto atende continuamente à demanda dos clientes.

No Galera Cluster, todos os servidores que fazem parte do cluster podem servir como um nó de espera. No entanto, se a região ou o cluster inteiro cair, como você poderá lidar com isso? A criação de um nó em espera fora da região ou rede específica de seu cluster é uma opção aqui.

Na seção a seguir, mostraremos como criar um nó em espera no AWS EC2 usando MariaDB.

Implantando um Hot Standby no Amazon AWS

Anteriormente, mostramos como você pode criar um Galera Cluster na AWS. Você pode querer ler Deploying MySQL Galera Cluster 4.0 on Amazon AWS EC2 caso você seja novo no Galera 4.0.

A implantação de seu nó de espera ativa pode ser em outro conjunto de Galera Cluster que usa replicação síncrona (consulte este blog Zero Downtime Network Migration With MySQL Galera Cluster Using Relay Node) ou implantando um nó MySQL/MariaDB assíncrono . Neste blog, vamos configurar e implantar o nó hot standby replicando de forma assíncrona de um dos nós Galera.

A configuração do cluster Galera

Nesta configuração de amostra, implantamos um cluster de 3 nós usando a versão MariaDB 10.4.8. Este cluster está sendo implantado na região Leste dos EUA (Ohio) e a topologia é mostrada abaixo:

Usaremos o servidor 172.31.26.175 como mestre para nosso escravo assíncrono que servirá como o nó de espera.

Configurando sua instância do EC2 para o nó de espera ativa

No console da AWS, vá para EC2 encontrado na seção Compute e clique em Launch Instance para criar uma instância do EC2 como abaixo.

Criaremos esta instância na região Oeste dos EUA (Oregon). Para o seu tipo de sistema operacional, você pode escolher qual servidor você gosta (prefiro o Ubuntu 18.04) e escolher o tipo de instância com base no seu tipo de destino preferido. Para este exemplo, usarei o t2.micro, pois ele não requer nenhuma configuração sofisticada e é apenas para esta implantação de exemplo.

Como mencionamos anteriormente, é melhor que seu nó de espera ativa esteja localizado em uma região diferente e não colocado ou dentro da mesma região. Portanto, caso o data center regional fique inativo ou sofra uma interrupção na rede, seu hot standby pode ser seu destino de failover quando as coisas derem errado.

Antes de continuarmos, na AWS, diferentes regiões terão sua própria Virtual Private Cloud (VPC) e sua própria rede. Para se comunicar com os nós do cluster Galera, devemos primeiro definir um VPC Peering para que os nós possam se comunicar dentro da infraestrutura da Amazon e não precisem sair da rede, o que apenas adiciona sobrecarga e preocupações de segurança.

Primeiro, vá para sua VPC de onde seu nó de espera ativa deve residir e, em seguida, vá para Conexões de emparelhamento. Em seguida, você precisa especificar a VPC do seu nó em espera e a VPC do cluster Galera. No exemplo abaixo, tenho us-west-2 interconectando-se a us-east-2.

Depois de criado, você verá uma entrada em suas conexões de emparelhamento. No entanto, você precisa aceitar a solicitação da VPC do cluster Galera, que está em us-east-2 neste exemplo. Ver abaixo,

Uma vez aceito, não se esqueça de adicionar o CIDR à tabela de roteamento. Consulte este blog externo VPC Peering sobre como fazer isso após o VPC Peering.

Agora, vamos voltar e continuar criando o nó EC2. Certifique-se de que seu grupo de segurança tenha as regras corretas ou as portas necessárias que precisam ser abertas. Verifique o manual de configurações do firewall para obter mais informações sobre isso. Para esta configuração, defini apenas todo o tráfego para ser aceito, pois este é apenas um teste. Ver abaixo,

Certifique-se de que, ao criar sua instância, você definiu a VPC correta e definiu sua sub-rede adequada. Você pode verificar este blog caso precise de alguma ajuda sobre isso.

Configurando o MariaDB Async Slave

Primeiro passo

Primeiro precisamos configurar o repositório, adicionar as chaves do repositório e atualizar a lista de pacotes no cache do repositório, 

$ vi /etc/apt/sources.list.d/mariadb.list

$ apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xF1656F24C74CD1D8

$ apt update

Passo Dois

Instale os pacotes MariaDB e seus binários necessários 

$ apt-get install mariadb-backup  mariadb-client mariadb-client-10.4 libmariadb3 libdbd-mysql-perl mariadb-client-core-10.4 mariadb-common mariadb-server-10.4 mariadb-server-core-10.4 mysql-common

Etapa Três

Agora, vamos fazer um backup usando xbstream para transferir os arquivos para a rede de um dos nós em nosso Cluster Galera.

## Limpe o diretório de dados do MySQL recém-instalado em seu nó de espera ativa. 

$ systemctl stop mariadb

$ rm -rf /var/lib/mysql/*

## Em seguida, no nó de espera ativa, execute isso no terminal, 

$ socat -u tcp-listen:9999,reuseaddr stdout 2>/tmp/netcat.log | mbstream -x -C /var/lib/mysql

## Em seguida, no mestre de destino, ou seja, um dos nós em seu cluster Galera (que é o nó 172.31.28.175 neste exemplo), execute isso no terminal, 

$ mariabackup  --backup --target-dir=/tmp --stream=xbstream | socat - TCP4:172.32.31.2:9999

onde 172.32.31.2 é o IP do nó em espera do host.

Passo Quatro

Prepare seu arquivo de configuração do MySQL. Como isso está no Ubuntu, estou editando o arquivo em /etc/mysql/my.cnf e com o seguinte exemplo my.cnf retirado do nosso modelo ClusterControl, 

[MYSQLD]

user=mysql

basedir=/usr/

datadir=/var/lib/mysql

socket=/var/lib/mysql/mysql.sock

pid_file=/var/lib/mysql/mysql.pid

port=3306

log_error=/var/log/mysql/mysqld.log

log_warnings=2

# log_output = FILE



#Slow logging    

slow_query_log_file=/var/log/mysql/mysql-slow.log

long_query_time=2

slow_query_log=OFF

log_queries_not_using_indexes=OFF



### INNODB OPTIONS

innodb_buffer_pool_size=245M

innodb_flush_log_at_trx_commit=2

innodb_file_per_table=1

innodb_data_file_path = ibdata1:100M:autoextend

## You may want to tune the below depending on number of cores and disk sub

innodb_read_io_threads=4

innodb_write_io_threads=4

innodb_doublewrite=1

innodb_log_file_size=64M

innodb_log_buffer_size=16M

innodb_buffer_pool_instances=1

innodb_log_files_in_group=2

innodb_thread_concurrency=0

# innodb_file_format = barracuda

innodb_flush_method = O_DIRECT

innodb_rollback_on_timeout=ON

# innodb_locks_unsafe_for_binlog = 1

innodb_autoinc_lock_mode=2

## avoid statistics update when doing e.g show tables

innodb_stats_on_metadata=0

default_storage_engine=innodb



# CHARACTER SET

# collation_server = utf8_unicode_ci

# init_connect = 'SET NAMES utf8'

# character_set_server = utf8



# REPLICATION SPECIFIC

server_id=1002

binlog_format=ROW

log_bin=binlog

log_slave_updates=1

relay_log=relay-bin

expire_logs_days=7

read_only=ON

report_host=172.31.29.72

gtid_ignore_duplicates=ON

gtid_strict_mode=ON



# OTHER THINGS, BUFFERS ETC

key_buffer_size = 24M

tmp_table_size = 64M

max_heap_table_size = 64M

max_allowed_packet = 512M

# sort_buffer_size = 256K

# read_buffer_size = 256K

# read_rnd_buffer_size = 512K

# myisam_sort_buffer_size = 8M

skip_name_resolve

memlock=0

sysdate_is_now=1

max_connections=500

thread_cache_size=512

query_cache_type = 0

query_cache_size = 0

table_open_cache=1024

lower_case_table_names=0

# 5.6 backwards compatibility (FIXME)

# explicit_defaults_for_timestamp = 1



performance_schema = OFF

performance-schema-max-mutex-classes = 0

performance-schema-max-mutex-instances = 0



[MYSQL]

socket=/var/lib/mysql/mysql.sock

# default_character_set = utf8

[client]

socket=/var/lib/mysql/mysql.sock

# default_character_set = utf8

[mysqldump]

socket=/var/lib/mysql/mysql.sock

max_allowed_packet = 512M

# default_character_set = utf8



[xtrabackup]



[MYSQLD_SAFE]

# log_error = /var/log/mysqld.log

basedir=/usr/

# datadir = /var/lib/mysql

Claro, você pode alterar isso de acordo com sua configuração e requisitos.

Passo Cinco

Prepare o backup da etapa 3, ou seja, o backup final que agora está no nó de espera ativa executando o comando abaixo, 

$ mariabackup --prepare --target-dir=/var/lib/mysql

Passo Seis

Defina a propriedade do datadir no nó de espera ativa, 

$ chown -R mysql.mysql /var/lib/mysql

Etapa Sete

Agora, inicie a instância MariaDB 

$  systemctl start mariadb

Etapa Oito

Por último, precisamos configurar a replicação assíncrona,

## Crie o usuário de replicação no nó mestre, ou seja, o nó no cluster Galera 

MariaDB [(none)]> CREATE USER 'cmon_replication'@'172.32.31.2' IDENTIFIED BY 'PahqTuS1uRIWYKIN';

Query OK, 0 rows affected (0.866 sec)

MariaDB [(none)]> GRANT REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'cmon_replication'@'172.32.31.2';

Query OK, 0 rows affected (0.127 sec)

## Obtenha a posição do escravo GTID de xtrabackup_binlog_info da seguinte forma, 

$  cat /var/lib/mysql/xtrabackup_binlog_info

binlog.000002   71131632 1000-1000-120454

##  Em seguida, configure a replicação escrava da seguinte maneira, 

MariaDB [(none)]> SET GLOBAL gtid_slave_pos='1000-1000-120454';

Query OK, 0 rows affected (0.053 sec)

MariaDB [(none)]> CHANGE MASTER TO MASTER_HOST='172.31.28.175', MASTER_USER='cmon_replication', master_password='PahqTuS1uRIWYKIN', MASTER_USE_GTID = slave_pos;

## Agora, verifique o status do escravo, 

MariaDB [(none)]> show slave status \G

*************************** 1. row ***************************

                Slave_IO_State: Waiting for master to send event

                   Master_Host: 172.31.28.175

                   Master_User: cmon_replication

                   Master_Port: 3306

                 Connect_Retry: 60

               Master_Log_File: 

           Read_Master_Log_Pos: 4

                Relay_Log_File: relay-bin.000001

                 Relay_Log_Pos: 4

         Relay_Master_Log_File: 

              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: 

                    Last_Errno: 0

                    Last_Error: 

                  Skip_Counter: 0

           Exec_Master_Log_Pos: 4

               Relay_Log_Space: 256

               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: 1000

                Master_SSL_Crl: 

            Master_SSL_Crlpath: 

                    Using_Gtid: Slave_Pos

                   Gtid_IO_Pos: 1000-1000-120454

       Replicate_Do_Domain_Ids: 

   Replicate_Ignore_Domain_Ids: 

                 Parallel_Mode: conservative

                     SQL_Delay: 0

           SQL_Remaining_Delay: NULL

       Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it

              Slave_DDL_Groups: 0

Slave_Non_Transactional_Groups: 0

    Slave_Transactional_Groups: 0

1 row in set (0.000 sec)

Adicionando seu nó Hot Standby ao ClusterControl

Se você estiver usando o ClusterControl, é fácil monitorar a integridade do servidor de banco de dados. Para adicioná-lo como escravo, selecione o cluster do nó Galera que você possui e vá para o botão de seleção conforme mostrado abaixo para Adicionar Escravo de Replicação:

Clique em Add Replication Slave e escolha adicionar um slave existente como abaixo,

Nossa topologia parece promissora.

Como você pode notar, nosso nó 172.32.31.2 servindo como nosso hot standby O nó tem um CIDR diferente que prefixa como 172.32.% us-west-2 (Oregon), enquanto os outros nós são de 172.31.% localizados em us-east-2 (Ohio). Eles estão totalmente em regiões diferentes, portanto, caso ocorra uma falha de rede em seus nós Galera, você pode fazer failover para seu nó de espera ativa.

Conclusão

Criar um Hot Standby no Amazon AWS é fácil e direto. Tudo o que você precisa é determinar seus requisitos de capacidade e sua topologia de rede, segurança e protocolos que precisam ser configurados.

O uso do VPC Peering ajuda a acelerar a intercomunicação entre diferentes regiões sem acessar a Internet pública, de modo que a conexão permaneça dentro da infraestrutura de rede da Amazon.

Usar a replicação assíncrona com um escravo, obviamente, não é suficiente, mas este blog serve como base sobre como você pode iniciar isso. Agora você pode facilmente criar outro cluster onde o escravo assíncrono está replicando e criar outra série de Clusters do Galera servindo como seus nós de recuperação de desastres, ou você também pode usar a variável gmcast.segment no Galera para replicar de forma síncrona como o que temos neste blog.