Vytvoření horkého pohotovostního režimu na Amazon AWS pomocí MariaDB Cluster

Galera Cluster 4.0 byla poprvé vydána jako součást MariaDB 10.4 a v této verzi je mnoho významných vylepšení. Nejpůsobivější funkcí v této verzi je Streaming Replication, která je navržena tak, aby zvládla následující problémy.

Problémy s dlouhými transakcemi
Problémy s velkými transakcemi
Problémy s aktivními body v tabulkách

V předchozím blogu jsme se hluboce ponořili do nové funkce replikace streamování v blogu dvoudílné série (část 1 a část 2). Součástí této nové funkce v Galera 4.0 jsou nové systémové tabulky, které jsou velmi užitečné pro dotazování a kontrolu uzlů Galera Cluster a také protokolů, které byly zpracovány v Streaming Replication.

V předchozích blozích jsme vám také ukázali snadný způsob nasazení MySQL Galera Cluster na AWS a také jak nasadit MySQL Galera Cluster 4.0 na Amazon AWS EC2.

Percona zatím nevydala GA pro svůj Percona XtraDB Cluster (PXC) 8.0, protože některé funkce jsou stále ve vývoji, jako je funkce MySQL wsrep WSREP_SYNC_WAIT_UPTO_GTID, která podle všeho ještě není (alespoň na verzi PXC 8.0.15-5-27dev.4.2). Přesto, až bude PXC 8.0 vydán, bude nabitý skvělými funkcemi, jako je...

Vylepšený odolný cluster
Cloud přátelský cluster
vylepšené balení
Podpora šifrování
Atomový DDL

Zatímco čekáme na vydání PXC 8.0 GA, v tomto blogu probereme, jak můžete vytvořit Hot Standby Node na Amazon AWS pro Galera Cluster 4.0 pomocí MariaDB.

Co je to horký pohotovostní režim?

Hot standby je běžný termín ve výpočetní technice, zejména na vysoce distribuovaných systémech. Je to metoda redundance, při které jeden systém běží současně s identickým primárním systémem. Když dojde k poruše na primárním uzlu, pohotovostní režim okamžitě převezme místo primárního systému. Data jsou zrcadlena do obou systémů v reálném čase.

U databázových systémů je horký pohotovostní server obvykle druhým uzlem po primárním hlavním serveru, který běží na výkonných prostředcích (stejných jako hlavní). Aby tento sekundární uzel správně fungoval, musí být stejně stabilní jako primární hlavní uzel.

Slouží také jako uzel pro obnovu dat, pokud selže hlavní uzel nebo celý cluster. Uzel v horkém pohotovostním režimu nahradí selhávající uzel nebo cluster a zároveň bude nepřetržitě obsluhovat požadavky klientů.

V Galera Cluster mohou všechny servery, které jsou součástí clusteru, sloužit jako pohotovostní uzel. Pokud však region nebo celý klastr klesne, jak se s tím budete moci vyrovnat? Jednou z možností je vytvoření pohotovostního uzlu mimo konkrétní oblast nebo síť vašeho clusteru.

V následující části vám ukážeme, jak vytvořit pohotovostní uzel na AWS EC2 pomocí MariaDB.

Nasazení Hot Standby na Amazon AWS

Dříve jsme vám ukázali, jak můžete vytvořit Galera Cluster na AWS. Možná si budete chtít přečíst Nasazení MySQL Galera Cluster 4.0 na Amazon AWS EC2 pro případ, že jste s Galera 4.0 noví.

Nasazení vašeho aktivního pohotovostního uzlu může být na jiné sadě Galera Cluster, který používá synchronní replikaci (podívejte se na tento blog Zero Downtime Network Migration With MySQL Galera Cluster Using Relay Node) nebo nasazením asynchronního MySQL/MariaDB uzlu . V tomto blogu nastavíme a nasadíme hot standby uzel, který se asynchronně replikuje z jednoho z uzlů Galera.

Nastavení Galera Cluster

V tomto ukázkovém nastavení jsme nasadili 3uzlový cluster pomocí MariaDB verze 10.4.8. Tento cluster je nasazován v oblasti východu USA (Ohio) a topologie je uvedena níže:

Jako hlavní server pro naši asynchronní podřízenou jednotku použijeme server 172.31.26.175 který bude sloužit jako pohotovostní uzel.

Nastavení instance EC2 pro uzel Hot Standby

V konzole AWS přejděte na EC2 v části Compute a kliknutím na Launch Instance vytvořte instanci EC2 stejně jako níže.

Tuto instanci vytvoříme v oblasti Západ USA (Oregon). Pro váš typ operačního systému si můžete vybrat, jaký server se vám líbí (preferuji Ubuntu 18.04) a vybrat typ instance na základě preferovaného cílového typu. Pro tento příklad použiji t2.micro, protože nevyžaduje žádné sofistikované nastavení a je určen pouze pro toto ukázkové nasazení.

Jak jsme již uvedli, je nejlepší, aby byl váš aktivní pohotovostní uzel umístěn v jiné oblasti a nebyl umístěn ve stejné oblasti. Takže v případě, že regionální datové centrum selže nebo utrpí výpadek sítě, může být váš horký pohotovostní režim vaším cílem přepnutí při selhání, když se něco pokazí.

Než budeme pokračovat, v AWS budou mít různé regiony svůj vlastní virtuální privátní cloud (VPC) a vlastní síť. Abychom mohli komunikovat s uzly clusteru Galera, musíme nejprve definovat VPC peering, aby uzly mohly komunikovat v rámci infrastruktury Amazonu a nemusely vycházet mimo síť, což jen zvyšuje režii a obavy o bezpečnost.

Nejprve přejděte do svého VPC, kde se bude nacházet váš hot standby uzel, a poté přejděte na Peering Connections. Poté musíte zadat VPC vašeho pohotovostního uzlu a VPC clusteru Galera. V níže uvedeném příkladu mám nás-západ-2 propojené s nám-východ-2.

Po vytvoření uvidíte položku pod peeringovými připojeními. Musíte však přijmout požadavek z VPC clusteru Galera, který je v tomto příkladu na nás-východ-2. Viz níže,

Po přijetí nezapomeňte přidat CIDR do směrovací tabulky. Podívejte se na tento externí blog VPC Peering o tom, jak to udělat po VPC Peering.

Nyní se vraťme a pokračujte ve vytváření uzlu EC2. Ujistěte se, že vaše skupina zabezpečení má správná pravidla nebo požadované porty, které je třeba otevřít. Další informace naleznete v příručce k nastavení brány firewall. Pro toto nastavení jsem pouze nastavil Veškerý provoz tak, aby byl přijat, protože se jedná pouze o test. Viz níže,

Při vytváření instance se ujistěte, že jste nastavili správné VPC a definovali vaši správnou podsíť. Můžete se podívat na tento blog, pokud byste s tím potřebovali pomoct.

Nastavení MariaDB Async Slave

Krok jedna

Nejprve musíme nastavit úložiště, přidat klíče úložiště a aktualizovat seznam balíčků v mezipaměti úložiště,

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

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

$ apt update

Krok dva

Nainstalujte balíčky MariaDB a jejich požadované binární soubory

$ 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

Krok tři

Nyní udělejme zálohu pomocí xbstream k přenosu souborů do sítě z jednoho z uzlů v našem clusteru Galera.

## Vymažte datadir nově čerstvě nainstalovaného MySQL ve vašem aktivním pohotovostním uzlu.

$ systemctl stop mariadb

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

## Poté v aktivním pohotovostním uzlu spusťte toto na terminálu,

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

## Poté na cílovém hlavním serveru, tj. jednom z uzlů ve vašem clusteru Galera (což je v tomto příkladu uzel 172.31.28.175), spusťte toto na terminálu,

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

kde 172.32.31.2 je IP pohotovostního uzlu hostitele.

Krok čtyři

Připravte si konfigurační soubor MySQL. Protože je to v Ubuntu, upravuji soubor v /etc/mysql/my.cnf a s následujícím příkladem my.cnf převzatým z naší šablony 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

Toto samozřejmě můžete změnit podle svého nastavení a požadavků.

Pátý krok

Připravte zálohu z kroku #3, tj. dokončete zálohu, která je nyní v aktivním pohotovostním uzlu spuštěním příkazu níže,

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

Krok šest

Nastavte vlastnictví datového adresáře v aktivním pohotovostním uzlu

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

Krok sedm

Nyní spusťte instanci MariaDB

$  systemctl start mariadb

Krok 8

Nakonec musíme nastavit asynchronní replikaci

## Vytvořte uživatele replikace na hlavním uzlu, tj. uzlu v clusteru 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)

## Získejte pozici GTID slave z xtrabackup_binlog_info následovně,

$  cat /var/lib/mysql/xtrabackup_binlog_info

binlog.000002   71131632 1000-1000-120454

## Poté nastavte replikaci slave následovně,

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;

## Nyní zkontrolujte stav 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)

Přidání uzlu aktivního pohotovostního režimu do ClusterControl

Pokud používáte ClusterControl, je snadné monitorovat stav databázového serveru. Chcete-li jej přidat jako podřízenou jednotku, vyberte cluster uzlů Galera, který máte, a poté přejděte na tlačítko výběru, jak je znázorněno níže, a přidejte podřízenou replikaci:

Klikněte na Přidat replikační podřízenou jednotku a zvolte přidání stávající podřízené jednotky jako níže,

Naše topologie vypadá slibně.

Jak jste si mohli všimnout, náš uzel 172.32.31.2 slouží jako náš aktivní pohotovostní režim uzel má jiný CIDR, který má předponu 172,32.% us-západ-2 (Oregon), zatímco ostatní uzly mají 172,31.% umístěné na us-východ-2 (Ohio). Jsou zcela v jiné oblasti, takže v případě, že dojde k selhání sítě na uzlech Galera, můžete přepnout na záložní uzel.

Závěr

Vytvoření Hot Standby na Amazon AWS je snadné a přímočaré. Vše, co potřebujete, je určit požadavky na kapacitu a topologii sítě, zabezpečení a protokoly, které je třeba nastavit.

Použití VPC Peering pomáhá urychlit vzájemnou komunikaci mezi různými regiony, aniž by bylo nutné přejít na veřejný internet, takže připojení zůstává v rámci síťové infrastruktury Amazon.

Použití asynchronní replikace s jedním slavem samozřejmě nestačí, ale tento blog slouží jako základ pro to, jak to můžete zahájit. Nyní můžete snadno vytvořit další cluster, kde se replikuje asynchronní slave, a vytvořit další řadu clusterů Galera sloužících jako vaše uzly zotavení po havárii, nebo můžete také použít proměnnou gmcast.segment v Galeře k synchronní replikaci, stejně jako to, co máme na tomto blogu.