Een hot stand-by bouwen op Amazon AWS met MariaDB Cluster

Galera Cluster 4.0 werd voor het eerst uitgebracht als onderdeel van MariaDB 10.4 en er zijn veel belangrijke verbeteringen in deze versie. De meest indrukwekkende functie in deze release is de streamingreplicatie die is ontworpen om de volgende problemen op te lossen.

Problemen met lange transacties
Problemen met grote transacties
Problemen met hotspots in tabellen

In een vorige blog hebben we ons verdiept in de nieuwe Streaming Replication-functie in een tweedelige serieblog (Deel 1 en Deel 2). Onderdeel van deze nieuwe functie in Galera 4.0 zijn nieuwe systeemtabellen die erg handig zijn voor het opvragen en controleren van de Galera Cluster-knooppunten en ook de logs die zijn verwerkt in Streaming Replication.

Ook in eerdere blogs hebben we u de gemakkelijke manier getoond om een MySQL Galera-cluster op AWS te implementeren en ook hoe u een MySQL Galera-cluster 4.0 op Amazon AWS EC2 kunt implementeren.

Percona heeft nog geen GA uitgebracht voor hun Percona XtraDB Cluster (PXC) 8.0 omdat sommige functies nog in ontwikkeling zijn, zoals de MySQL wsrep-functie WSREP_SYNC_WAIT_UPTO_GTID die nog niet aanwezig lijkt te zijn (tenminste op PXC 8.0.15-5-27dev.4.2 versie). Maar als PXC 8.0 wordt uitgebracht, zit het boordevol geweldige functies zoals...

Verbeterde veerkrachtige cluster
Cloudvriendelijk cluster
verbeterde verpakking
Encryptie-ondersteuning
Atomic DDL

Terwijl we wachten op de release van PXC 8.0 GA, bespreken we in deze blog hoe je een Hot Standby Node kunt maken op Amazon AWS voor Galera Cluster 4.0 met MariaDB.

Wat is een Hot Standby?

Hot stand-by is een veelgebruikte term in computers, vooral op sterk gedistribueerde systemen. Het is een methode voor redundantie waarbij één systeem tegelijk draait met een identiek primair systeem. Wanneer er een storing optreedt op het primaire knooppunt, neemt de hot standby onmiddellijk de vervanging van het primaire systeem over. Gegevens worden in realtime naar beide systemen gespiegeld.

Voor databasesystemen is een hot-standbyserver meestal het tweede knooppunt na de primaire master dat op krachtige bronnen draait (hetzelfde als de master). Dit secundaire knooppunt moet net zo stabiel zijn als de primaire master om correct te kunnen functioneren.

Het dient ook als een gegevensherstelknooppunt als het hoofdknooppunt of het hele cluster uitvalt. Het hot standby-knooppunt vervangt het defecte knooppunt of cluster terwijl het continu aan de vraag van de clients voldoet.

In Galera Cluster kunnen alle servers die deel uitmaken van het cluster dienen als een stand-by node. Maar als de regio of het hele cluster uitvalt, hoe ga je daar dan mee om? Een standby-knooppunt maken buiten de specifieke regio of het specifieke netwerk van uw cluster is hier een optie.

In het volgende gedeelte laten we u zien hoe u een stand-by-knooppunt op AWS EC2 maakt met MariaDB.

Een Hot Standby implementeren op Amazon AWS

Eerder hebben we u laten zien hoe u een Galera-cluster kunt maken op AWS. Misschien wilt u MySQL Galera Cluster 4.0 implementeren op Amazon AWS EC2 lezen in het geval dat Galera 4.0 nieuw voor u is.

Het implementeren van uw hot standby-knooppunt kan op een andere set van Galera Cluster die synchrone replicatie gebruikt (bekijk deze blog Zero Downtime Network Migration With MySQL Galera Cluster Using Relay Node) of door een asynchrone MySQL/MariaDB-node te implementeren . In deze blog zullen we het hot standby-knooppunt instellen en implementeren dat asynchroon repliceert vanaf een van de Galera-knooppunten.

De Galera-clusterconfiguratie

In deze voorbeeldconfiguratie hebben we een cluster met 3 knooppunten geïmplementeerd met MariaDB 10.4.8-versie. Dit cluster wordt geïmplementeerd in de regio VS-Oost (Ohio) en de topologie wordt hieronder weergegeven:

We gebruiken de 172.31.26.175-server als de master voor onze asynchrone slave die zal dienen als de standby-node.

Uw EC2-instantie instellen voor Hot Standby Node

Ga in de AWS-console naar EC2 onder het gedeelte Berekenen en klik op Instantie starten om een EC2-instantie te maken, zoals hieronder.

We maken deze instantie in de regio US West (Oregon). Voor uw type besturingssysteem kunt u kiezen welke server u leuk vindt (ik geef de voorkeur aan Ubuntu 18.04) en het type instantie kiezen op basis van uw gewenste doeltype. Voor dit voorbeeld zal ik t2.micro gebruiken omdat er geen geavanceerde instellingen voor nodig zijn en het alleen voor deze voorbeeldimplementatie is.

Zoals we eerder hebben vermeld, is het het beste dat uw hot standby-knooppunt zich in een andere regio bevindt en niet bij elkaar of in dezelfde regio. Dus in het geval dat het regionale datacenter uitvalt of een netwerkstoring heeft, kan uw hot standby uw failover-doelwit zijn als het misgaat.

Voordat we verder gaan, zullen in AWS verschillende regio's hun eigen Virtual Private Cloud (VPC) en een eigen netwerk hebben. Om te communiceren met de Galera-clusterknooppunten, moeten we eerst een VPC-peering definiëren, zodat de knooppunten kunnen communiceren binnen de Amazon-infrastructuur en niet buiten het netwerk hoeven te gaan, wat alleen maar overhead en beveiligingsproblemen met zich meebrengt.

Ga eerst naar uw VPC vanwaar uw hot standby-knooppunt zich bevindt en ga vervolgens naar Peering-verbindingen. Vervolgens moet u de VPC van uw standby-knooppunt en de Galera-cluster-VPC specificeren. In het onderstaande voorbeeld heb ik us-west-2 verbonden met us-east-2.

Eenmaal aangemaakt, zie je een item onder je peeringverbindingen. U moet echter het verzoek accepteren van de Galera-cluster VPC, die zich in dit voorbeeld op us-east-2 bevindt. Zie hieronder,

Vergeet na acceptatie niet de CIDR toe te voegen aan de routeringstabel. Bekijk deze externe blog VPC Peering over hoe je dit kunt doen na VPC Peering.

Laten we nu teruggaan en doorgaan met het maken van de EC2-node. Zorg ervoor dat uw beveiligingsgroep de juiste regels of vereiste poorten heeft die moeten worden geopend. Raadpleeg de handleiding van de firewall-instellingen voor meer informatie hierover. Voor deze configuratie heb ik zojuist al het verkeer ingesteld om te worden geaccepteerd, omdat dit slechts een test is. Zie hieronder,

Zorg ervoor dat u bij het maken van uw instantie de juiste VPC hebt ingesteld en uw juiste subnet hebt gedefinieerd. Je kunt deze blog raadplegen voor het geval je daar hulp bij nodig hebt.

De MariaDB Async Slave instellen

Stap één

Eerst moeten we de repository instellen, de repo-sleutels toevoegen en de pakketlijst in de repository-cache bijwerken,

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

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

$ apt update

Stap twee

Installeer de MariaDB-pakketten en de vereiste binaire bestanden

$ 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

Stap drie

Laten we nu een back-up maken met xbstream om de bestanden naar het netwerk over te brengen vanaf een van de knooppunten in onze Galera-cluster.

## Wis de datadir van de nieuw geïnstalleerde MySQL in uw hot standby-knooppunt.

$ systemctl stop mariadb

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

## Voer dit vervolgens op de hot standby-node uit op de terminal,

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

## Voer dit vervolgens uit op de doelmaster, d.w.z. een van de knooppunten in uw Galera-cluster (het knooppunt 172.31.28.175 in dit voorbeeld),

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

waar 172.32.31.2 het IP-adres is van de host-standby-node.

Stap vier

Maak uw MySQL-configuratiebestand klaar. Aangezien dit in Ubuntu is, bewerk ik het bestand in /etc/mysql/my.cnf en met het volgende voorbeeld my.cnf uit onze ClusterControl-sjabloon,

[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

Natuurlijk kunt u dit aanpassen aan uw instellingen en vereisten.

Stap vijf

Bereid de back-up van stap #3 voor, d.w.z. de voltooi de back-up die zich nu in de hot standby-node bevindt door de onderstaande opdracht uit te voeren,

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

Stap zes

Stel het eigendom van de datadir in op het hot standby-knooppunt,

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

Stap zeven

Start nu de MariaDB-instantie

$  systemctl start mariadb

Stap acht

Ten slotte moeten we de asynchrone replicatie instellen,

## Maak de replicatiegebruiker op het hoofdknooppunt, d.w.z. het knooppunt in het Galera-cluster

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)

## Haal als volgt de GTID-slavepositie van xtrabackup_binlog_info op,

$  cat /var/lib/mysql/xtrabackup_binlog_info

binlog.000002   71131632 1000-1000-120454

## Stel vervolgens de slave-replicatie als volgt in,

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;

## Controleer nu de slave-status,

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)

Uw Hot Standby Node toevoegen aan ClusterControl

Als u ClusterControl gebruikt, is het eenvoudig om de gezondheid van uw databaseserver te controleren. Om dit als slave toe te voegen, selecteert u het Galera-knooppuntcluster dat u hebt en gaat u naar de selectieknop zoals hieronder weergegeven om Replication Slave toe te voegen:

Klik op Replicatieslave toevoegen en kies het toevoegen van een bestaande slave, zoals hieronder,

Onze topologie ziet er veelbelovend uit.

Zoals u wellicht opmerkt, dient onze node 172.32.31.2 als onze hot standby node heeft een andere CIDR met als prefix 172,32.% us-west-2 (Oregon), terwijl de andere nodes van 172.31.% zich op us-east-2 (Ohio) bevinden. Ze bevinden zich totaal in een andere regio, dus als er een netwerkstoring optreedt op uw Galera-knooppunten, kunt u een failover uitvoeren naar uw hot-stand-by-knooppunt.

Conclusie

Het bouwen van een Hot Standby op Amazon AWS is eenvoudig en ongecompliceerd. Het enige dat u nodig hebt, is het bepalen van uw capaciteitsvereisten en uw netwerktopologie, beveiliging en protocollen die moeten worden ingesteld.

Het gebruik van VPC-peering helpt de onderlinge communicatie tussen verschillende regio's te versnellen zonder naar het openbare internet te gaan, zodat de verbinding binnen de Amazon-netwerkinfrastructuur blijft.

Het gebruik van asynchrone replicatie met één slave is natuurlijk niet voldoende, maar deze blog dient als basis hoe je dit kunt initiëren. U kunt nu eenvoudig een ander cluster maken waar de asynchrone slaaf repliceert en een andere reeks Galera-clusters maken die als uw Disaster Recovery-knooppunten dienen, of u kunt ook de gmcast.segment-variabele in Galera gebruiken om synchroon te repliceren, net zoals we op deze blog hebben.