Opbygning af en Hot Standby på Amazon AWS ved hjælp af MariaDB Cluster

Galera Cluster 4.0 blev først udgivet som en del af MariaDB 10.4, og der er en masse væsentlige forbedringer i denne versionsudgivelse. Den mest imponerende funktion i denne udgivelse er Streaming-replikeringen, som er designet til at håndtere følgende problemer.

Problemer med lange transaktioner
Problemer med store transaktioner
Problemer med hotspots i tabeller

I en tidligere blog dykker vi dybt ned i den nye streamingreplikeringsfunktion i en todelt serieblog (del 1 og del 2). En del af denne nye funktion i Galera 4.0 er nye systemtabeller, som er meget nyttige til at forespørge og kontrollere Galera Cluster-noder og også de logfiler, der er blevet behandlet i Streaming Replication.

I tidligere blogs har vi også vist dig den nemme måde at implementere en MySQL Galera Cluster på AWS og også hvordan du implementerer en MySQL Galera Cluster 4.0 på Amazon AWS EC2.

Percona har endnu ikke udgivet en GA til deres Percona XtraDB Cluster (PXC) 8.0, da nogle funktioner stadig er under udvikling, såsom MySQL wsrep-funktionen WSREP_SYNC_WAIT_UPTO_GTID, der ser ud til ikke at være til stede endnu (i det mindste) på PXC 8.0.15-5-27dev.4.2 version). Men når PXC 8.0 udgives, vil den være spækket med fantastiske funktioner såsom...

Forbedret modstandsdygtig klynge
Skyvenlig klynge
forbedret emballage
Krypteringsunderstøttelse
Atomic DDL

Mens vi venter på udgivelsen af PXC 8.0 GA, dækker vi i denne blog, hvordan du kan oprette en Hot Standby Node på Amazon AWS til Galera Cluster 4.0 ved hjælp af MariaDB.

Hvad er en Hot Standby?

En varm standby er et almindeligt begreb inden for computere, især på højt distribuerede systemer. Det er en metode til redundans, hvor et system kører samtidigt med et identisk primært system. Når der opstår fejl på den primære knude, overtager den varme standby straks og erstatter det primære system. Data spejles til begge systemer i realtid.

For databasesystemer er en hot standby-server normalt den anden node efter den primære master, der kører på kraftfulde ressourcer (samme som masteren). Denne sekundære node skal være lige så stabil som den primære master for at fungere korrekt.

Det fungerer også som en datagendannelsesknude, hvis masternoden eller hele klyngen går ned. Den varme standby-knude vil erstatte den svigtende node eller klynge, mens den konstant betjener efterspørgslen fra klienterne.

I Galera Cluster kan alle servere, der er en del af klyngen, fungere som en standby-knude. Men hvis regionen eller hele klyngen går ned, hvordan vil du så være i stand til at klare dette? Oprettelse af en standby-knude uden for den specifikke region eller netværk i din klynge er en mulighed her.

I det følgende afsnit viser vi dig, hvordan du opretter en standby-node på AWS EC2 ved hjælp af MariaDB.

Installation af en Hot Standby på Amazon AWS

Tidligere har vi vist dig, hvordan du kan oprette en Galera-klynge på AWS. Du vil måske læse Deploying MySQL Galera Cluster 4.0 på Amazon AWS EC2 i tilfælde af, at du er ny til Galera 4.0.

Du kan implementere din hot-standby node på et andet sæt Galera Cluster, som bruger synkron replikering (tjek denne blog Zero Downtime Network Migration With MySQL Galera Cluster Using Relay Node) eller ved at implementere en asynkron MySQL/MariaDB-node . I denne blog opsætter og implementerer vi den varme standby-knude, der replikerer asynkront fra en af Galera-knuderne.

Galera-klyngeopsætningen

I denne eksempelopsætning implementerede vi 3-node klynge ved hjælp af MariaDB 10.4.8 version. Denne klynge er ved at blive udrullet under US East (Ohio) region, og topologien er vist nedenfor:

Vi bruger 172.31.26.175-serveren som master for vores asynkrone slave som vil fungere som standby-knudepunktet.

Opsætning af din EC2-instans til Hot Standby Node

I AWS-konsollen skal du gå til EC2, der findes under Compute-sektionen, og klikke på Launch Instance for at oprette en EC2-instans ligesom nedenfor.

Vi opretter denne forekomst under regionen US West (Oregon). For din OS-type kan du vælge hvilken server du kan lide (jeg foretrækker Ubuntu 18.04) og vælge typen af instans baseret på din foretrukne måltype. Til dette eksempel vil jeg bruge t2.micro, da det ikke kræver nogen sofistikeret opsætning, og det kun er til denne prøveinstallation.

Som vi har nævnt tidligere, er det bedst, at din hot-standby-knude er placeret i en anden region og ikke samlokaliseret eller inden for samme region. Så i tilfælde af at det regionale datacenter går ned eller lider af et netværksudfald, kan din varme standby være dit failover-mål, når tingene gik dårligt.

Før vi fortsætter, i AWS, vil forskellige regioner have sin egen Virtual Private Cloud (VPC) og sit eget netværk. For at kunne kommunikere med Galera-klyndeknuderne skal vi først definere en VPC-peering, så noderne kan kommunikere inden for Amazon-infrastrukturen og ikke behøver at gå uden for netværket, hvilket blot tilføjer overhead- og sikkerhedsproblemer.

Først skal du gå til din VPC, hvorfra din hot-standby-knude skal ligge, og derefter gå til Peering-forbindelser. Derefter skal du angive VPC'en for din standby-knude og Galera-klyngen VPC. I eksemplet nedenfor har jeg us-west-2 forbundet med us-east-2.

Når den er oprettet, vil du se en post under dine Peering-forbindelser. Du skal dog acceptere anmodningen fra Galera cluster VPC, som er på us-east-2 i dette eksempel. Se nedenfor,

Når du er accepteret, så glem ikke at tilføje CIDR til routingtabellen. Se denne eksterne blog VPC Peering om, hvordan du gør det efter VPC Peering.

Lad os nu gå tilbage og fortsætte med at skabe EC2-knuden. Sørg for, at din sikkerhedsgruppe har de korrekte regler eller påkrævede porte, der skal åbnes. Se manualen til firewall-indstillinger for mere information om dette. Til denne opsætning har jeg netop indstillet Al trafik til at blive accepteret, da dette kun er en test. Se nedenfor,

Sørg for, at når du opretter din instans, har du indstillet den korrekte VPC, og du har defineret dit rigtige undernet. Du kan tjekke denne blog, hvis du har brug for hjælp til det.

Opsætning af MariaDB Async Slave

Trin 1

Først skal vi konfigurere lageret, tilføje repo-nøglerne og opdatere pakkelisten i lagercachen,

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

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

$ apt update

Trin to

Installer MariaDB-pakkerne og de nødvendige binære filer

$ 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

Trin tre

Lad os nu tage en sikkerhedskopi ved hjælp af xbstream for at overføre filerne til netværket fra en af noderne i vores Galera Cluster.

## Slet datadirigenten for den nyligt installerede MySQL i din hot standby node.

$ systemctl stop mariadb

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

## Kør derefter dette på den varme standby-knude på terminalen,

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

## Kør derefter dette på terminalen, dvs. en af noderne i din Galera Cluster (som er noden 172.31.28.175 i dette eksempel),

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

hvor 172.32.31.2 er IP-adressen for værtens standby-knude.

Trin fire

Forbered din MySQL-konfigurationsfil. Da dette er i Ubuntu, redigerer jeg filen i /etc/mysql/my.cnf og med følgende eksempel på my.cnf taget fra vores ClusterControl-skabelon,

[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

Selvfølgelig kan du ændre dette i henhold til din opsætning og dine krav.

Trin fem

Forbered sikkerhedskopien fra trin #3, dvs. den afsluttende sikkerhedskopiering, der nu er i den varme standby-knude ved at køre kommandoen nedenfor,

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

Trin seks

Indstil ejerskabet af datadirigent i hot standby noden,

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

Trin syv

Start nu MariaDB-forekomsten

$  systemctl start mariadb

Trin otte

Til sidst skal vi konfigurere den asynkrone replikering,

## Opret replikeringsbrugeren på masternoden, dvs. noden i Galera-klyngen

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)

## Hent GTID-slavepositionen fra xtrabackup_binlog_info som følger,

$  cat /var/lib/mysql/xtrabackup_binlog_info

binlog.000002   71131632 1000-1000-120454

## Opsæt derefter slavereplikeringen som følger,

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;

## Tjek nu slavestatus,

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)

Tilføjelse af din Hot Standby Node til ClusterControl

Hvis du bruger ClusterControl, er det nemt at overvåge din databaseservers tilstand. For at tilføje dette som en slave, vælg den Galera-nodeklynge, du har, og gå derefter til valgknappen som vist nedenfor for at tilføje replikeringsslave:

Klik på Tilføj replikeringsslave, og vælg at tilføje en eksisterende slave ligesom nedenfor,

Vores topologi ser lovende ud.

Som du måske bemærker, fungerer vores node 172.32.31.2 som vores hot standby node har en anden CIDR som præfikser som 172.32.% us-west-2 (Oregon), mens de andre noder er på 172.31.% placeret på us-east-2 (Ohio). De er helt i en anden region, så hvis der opstår netværksfejl på dine Galera-noder, kan du failover til din hot-standby-node.

Konklusion

Det er nemt og ligetil at bygge en Hot Standby på Amazon AWS. Alt du behøver er at bestemme dine kapacitetskrav og din netværkstopologi, sikkerhed og protokoller, der skal konfigureres.

Brug af VPC Peering hjælper med at fremskynde interkommunikation mellem forskellige regioner uden at gå til det offentlige internet, så forbindelsen forbliver inden for Amazons netværksinfrastruktur.

At bruge asynkron replikering med én slave er selvfølgelig ikke nok, men denne blog fungerer som grundlaget for, hvordan du kan igangsætte dette. Du kan nu nemt oprette en anden klynge, hvor den asynkrone slave replikerer, og oprette en anden serie af Galera-klynger, der fungerer som dine Disaster Recovery-noder, eller du kan også bruge gmcast.segment-variablen i Galera til at replikere synkront ligesom det, vi har på denne blog.