MariaDB
 sql >> Database >  >> RDS >> MariaDB

Creazione di un Hot Standby su Amazon AWS utilizzando MariaDB Cluster

Galera Cluster 4.0 è stato rilasciato per la prima volta come parte di MariaDB 10.4 e ci sono molti miglioramenti significativi in ​​questa versione. La caratteristica più impressionante di questa versione è la replica in streaming, progettata per gestire i seguenti problemi.

  • Problemi con transazioni lunghe
  • Problemi con transazioni di grandi dimensioni
  • Problemi con gli hotspot nelle tabelle

In un blog precedente, abbiamo approfondito la nuova funzione di replica in streaming in una serie di blog in due parti (parte 1 e parte 2). Parte di questa nuova funzionalità in Galera 4.0 sono le nuove tabelle di sistema che sono molto utili per interrogare e controllare i nodi del cluster Galera e anche i log che sono stati elaborati in Streaming Replication.

Anche nei blog precedenti, ti abbiamo mostrato anche il modo semplice per distribuire un cluster MySQL Galera su AWS e anche come distribuire un cluster MySQL Galera 4.0 su Amazon AWS EC2.

Percona non ha ancora rilasciato una GA per il proprio Percona XtraDB Cluster (PXC) 8.0 poiché alcune funzionalità sono ancora in fase di sviluppo, come la funzione MySQL wsrep WSREP_SYNC_WAIT_UPTO_GTID che sembra non essere ancora presente (almeno sulla versione PXC 8.0.15-5-27dev.4.2). Tuttavia, quando PXC 8.0 verrà rilasciato, sarà ricco di fantastiche funzionalità come...

  • Cluster resiliente migliorato
  • Cluster compatibile con il cloud
  • imballaggio migliorato
  • Supporto per la crittografia
  • DDL atomico

In attesa del rilascio di PXC 8.0 GA, in questo blog parleremo di come creare un Hot Standby Node su Amazon AWS per Galera Cluster 4.0 utilizzando MariaDB.

Cos'è un Hot Standby?

Un hot standby è un termine comune nell'informatica, specialmente su sistemi altamente distribuiti. È un metodo per la ridondanza in cui un sistema viene eseguito contemporaneamente con un sistema primario identico. Quando si verifica un errore sul nodo primario, l'hot standby subentra immediatamente sostituendo il sistema primario. I dati vengono rispecchiati su entrambi i sistemi in tempo reale.

Per i sistemi di database, un server hot standby è solitamente il secondo nodo dopo il master primario che è in esecuzione su risorse potenti (come il master). Questo nodo secondario deve essere stabile quanto il master primario per funzionare correttamente.

Serve anche come nodo di recupero dati se il nodo master o l'intero cluster si interrompe. Il nodo hot standby sostituirà il nodo o il cluster in errore mentre serve continuamente la domanda dei client.

In Galera Cluster, tutti i server che fanno parte del cluster possono fungere da nodo standby. Tuttavia, se la regione o l'intero cluster crolla, come sarai in grado di farcela? La creazione di un nodo di standby al di fuori della regione o della rete specifica del tuo cluster è un'opzione qui.

Nella sezione seguente, ti mostreremo come creare un nodo standby su AWS EC2 utilizzando MariaDB.

Distribuzione di un Hot Standby su Amazon AWS

In precedenza, ti abbiamo mostrato come creare un cluster Galera su AWS. Potresti voler leggere Distribuzione di MySQL Galera Cluster 4.0 su Amazon AWS EC2 nel caso in cui non conosci Galera 4.0.

La distribuzione del nodo hot standby può avvenire su un altro set di Galera Cluster che utilizza la replica sincrona (consulta questo blog Zero downtime Network Migration With MySQL Galera Cluster Using Relay Node) o distribuendo un nodo MySQL/MariaDB asincrono . In questo blog, configureremo e implementeremo il nodo hot standby replicandolo in modo asincrono da uno dei nodi Galera.

La configurazione del cluster Galera

In questa configurazione di esempio, abbiamo distribuito un cluster a 3 nodi utilizzando la versione MariaDB 10.4.8. Questo cluster viene distribuito nella regione degli Stati Uniti orientali (Ohio) e la topologia è mostrata di seguito:

Utilizzeremo il server 172.31.26.175 come master per il nostro slave asincrono che fungerà da nodo di standby.

Configurazione dell'istanza EC2 per Hot Standby Node

Nella console AWS, vai a EC2 che si trova nella sezione Calcolo e fai clic su Avvia istanza per creare un'istanza EC2 come di seguito.

Creeremo questa istanza nella regione degli Stati Uniti occidentali (Oregon). Per il tuo tipo di sistema operativo, puoi scegliere quale server ti piace (preferisco Ubuntu 18.04) e scegliere il tipo di istanza in base al tuo tipo di destinazione preferito. Per questo esempio userò t2.micro poiché non richiede alcuna configurazione sofisticata ed è solo per questa distribuzione di esempio.

Come accennato in precedenza, è meglio che il tuo nodo hot standby si trovi in ​​una regione diversa e non collocato o all'interno della stessa regione. Quindi, nel caso in cui il data center regionale si interrompa o subisca un'interruzione della rete, il tuo hot standby può essere la tua destinazione di failover quando le cose vanno male.

Prima di continuare, in AWS, diverse regioni avranno il proprio Virtual Private Cloud (VPC) e la propria rete. Per comunicare con i nodi del cluster Galera, dobbiamo prima definire un peering VPC in modo che i nodi possano comunicare all'interno dell'infrastruttura Amazon e non debbano uscire dalla rete, il che aggiunge solo problemi di sovraccarico e sicurezza.

In primo luogo, vai al tuo VPC da dove risiederà il tuo nodo hot standby, quindi vai a Connessioni peering. Quindi devi specificare il VPC del tuo nodo di standby e il VPC del cluster Galera. Nell'esempio seguente, ho us-west-2 interconnesso a us-east-2.

Una volta creato, vedrai una voce sotto le tue connessioni peering. Tuttavia, devi accettare la richiesta dal VPC del cluster Galera, che in questo esempio si trova su us-east-2. Vedi sotto,

Una volta accettato, non dimenticare di aggiungere il CIDR alla tabella di routing. Vedi questo blog esterno Peering VPC su come farlo dopo il peering VPC.

Ora, torniamo indietro e continuiamo a creare il nodo EC2. Assicurati che il tuo gruppo di sicurezza abbia le regole corrette o le porte richieste che devono essere aperte. Controllare il manuale delle impostazioni del firewall per ulteriori informazioni al riguardo. Per questa configurazione, ho semplicemente impostato Tutto il traffico in modo che sia accettato poiché si tratta solo di un test. Vedi sotto,

Assicurati che durante la creazione dell'istanza di aver impostato il VPC corretto e di hai definito la tua sottorete corretta. Puoi controllare questo blog nel caso avessi bisogno di aiuto a riguardo.

Configurazione dello slave asincrono MariaDB

Fase uno

Per prima cosa dobbiamo configurare il repository, aggiungere le chiavi del repository e aggiornare l'elenco dei pacchetti nella cache del repository,

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

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

$ apt update

Fase due

Installa i pacchetti MariaDB ei suoi binari richiesti

$ 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

Fase tre

Ora, eseguiamo un backup utilizzando xbstream per trasferire i file in rete da uno dei nodi nel nostro Cluster Galera.

## Cancella la datadir del MySQL appena installato nel tuo nodo hot standby.

$ systemctl stop mariadb

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

## Quindi sul nodo hot standby, eseguilo sul terminale,

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

## Quindi sul master di destinazione, ovvero uno dei nodi nel tuo cluster Galera (che in questo esempio è il nodo 172.31.28.175), eseguilo sul terminale,

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

dove 172.32.31.2 è l'IP del nodo host standby.

Fase quattro

Prepara il tuo file di configurazione MySQL. Poiché questo è in Ubuntu, sto modificando il file in /etc/mysql/my.cnf e con il seguente esempio my.cnf tratto dal nostro modello 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

Ovviamente, puoi modificarlo in base alla tua configurazione e ai tuoi requisiti.

Fase Cinque

Prepara il backup dal passaggio n. 3, ovvero il backup finale che si trova ora nel nodo hot standby eseguendo il comando seguente,

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

Sesto passo

Imposta la proprietà della datadir nel nodo hot standby,

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

Passo sette

Ora avvia l'istanza MariaDB

$  systemctl start mariadb

Passo otto

Infine, dobbiamo impostare la replica asincrona,

## Crea l'utente di replica sul nodo master, ovvero il nodo nel 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)

## Ottieni la posizione dello slave GTID da xtrabackup_binlog_info come segue,

$  cat /var/lib/mysql/xtrabackup_binlog_info

binlog.000002   71131632 1000-1000-120454

##  Quindi imposta la replica slave come segue,

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;

## Ora controlla lo stato dello slave,

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)

Aggiunta del tuo nodo Hot Standby a ClusterControl

Se si utilizza ClusterControl, è facile monitorare lo stato del server del database. Per aggiungerlo come slave, seleziona il cluster di nodi Galera che hai, quindi vai al pulsante di selezione come mostrato di seguito per Aggiungi slave di replica:

Fai clic su Aggiungi replica slave e scegli di aggiungere uno slave esistente proprio come di seguito,

La nostra topologia sembra promettente.

Come potresti notare, il nostro nodo 172.32.31.2 funge da hot standby il nodo ha un CIDR diverso che ha come prefisso 172.32.% us-west-2 (Oregon) mentre gli altri nodi sono del 172.31.% situati su us-east-2 (Ohio). Sono totalmente in una regione diversa, quindi nel caso in cui si verifichi un errore di rete sui tuoi nodi Galera, puoi eseguire il failover sul tuo nodo hot standby.

Conclusione

Creare un Hot Standby su Amazon AWS è facile e diretto. Tutto ciò che serve è determinare i requisiti di capacità e la topologia di rete, la sicurezza e i protocolli che devono essere configurati.

L'utilizzo del peering VPC aiuta a velocizzare l'intercomunicazione tra regioni diverse senza accedere alla rete Internet pubblica, in modo che la connessione rimanga all'interno dell'infrastruttura di rete Amazon.

L'uso della replica asincrona con uno slave, ovviamente, non è sufficiente, ma questo blog funge da base su come avviarlo. Ora puoi creare facilmente un altro cluster in cui lo slave asincrono si sta replicando e creare un'altra serie di cluster Galera che fungono da nodi di ripristino di emergenza, oppure puoi anche utilizzare la variabile gmcast.segment in Galera per replicare in modo sincrono proprio come quello che abbiamo su questo blog.