Bygga en Hot Standby på Amazon AWS med MariaDB Cluster

Galera Cluster 4.0 släpptes först som en del av MariaDB 10.4 och det finns många betydande förbättringar i den här versionsversionen. Den mest imponerande funktionen i den här utgåvan är Streaming Replication som är utformad för att hantera följande problem.

Problem med långa transaktioner
Problem med stora transaktioner
Problem med hotspots i tabeller

I en tidigare blogg fördjupade vi oss i den nya strömningsreplikeringsfunktionen i en tvådelad serieblogg (del 1 och del 2). En del av denna nya funktion i Galera 4.0 är nya systemtabeller som är mycket användbara för att fråga och kontrollera Galera Cluster-noderna och även loggarna som har bearbetats i Streaming Replication.

Också i tidigare bloggar har vi också visat dig det enkla sättet att distribuera ett MySQL Galera Cluster på AWS och även hur du distribuerar ett MySQL Galera Cluster 4.0 på Amazon AWS EC2.

Percona har inte släppt en GA för deras Percona XtraDB Cluster (PXC) 8.0 ännu eftersom vissa funktioner fortfarande är under utveckling, till exempel MySQL wsrep-funktionen WSREP_SYNC_WAIT_UPTO_GTID som ser ut att inte finnas ännu (åtminstone). på PXC 8.0.15-5-27dev.4.2 version). Men när PXC 8.0 kommer att släppas kommer den att vara fullspäckad med fantastiska funktioner som...

Förbättrat motståndskraftigt kluster
Molnvänligt kluster
förbättrad förpackning
Krypteringsstöd
Atomic DDL

Medan vi väntar på lanseringen av PXC 8.0 GA kommer vi i den här bloggen att ta upp hur du kan skapa en Hot Standby Node på Amazon AWS för Galera Cluster 4.0 med MariaDB.

Vad är en Hot Standby?

Hot standby är en vanlig term inom datoranvändning, särskilt på högdistribuerade system. Det är en metod för redundans där ett system körs samtidigt med ett identiskt primärt system. När ett fel inträffar på den primära noden, tar hot standby omedelbart över och ersätter det primära systemet. Data speglas till båda systemen i realtid.

För databassystem är en hot standby-server vanligtvis den andra noden efter den primära mastern som körs på kraftfulla resurser (samma som mastern). Denna sekundära nod måste vara lika stabil som den primära mastern för att fungera korrekt.

Den fungerar också som en dataåterställningsnod om huvudnoden eller hela klustret går ner. Hot standby-noden kommer att ersätta den misslyckade noden eller klustret samtidigt som den kontinuerligt betjänar efterfrågan från klienterna.

I Galera Cluster kan alla servrar som ingår i klustret fungera som en standby-nod. Men om regionen eller hela klustret går ner, hur kommer du att kunna hantera detta? Att skapa en standby-nod utanför den specifika regionen eller nätverket i ditt kluster är ett alternativ här.

I följande avsnitt visar vi dig hur du skapar en standby-nod på AWS EC2 med MariaDB.

Distribuera en Hot Standby på Amazon AWS

Tidigare har vi visat dig hur du kan skapa ett Galera-kluster på AWS. Du kanske vill läsa Distribuera MySQL Galera Cluster 4.0 på Amazon AWS EC2 om du är ny på Galera 4.0.

Du kan distribuera din heta standby-nod på en annan uppsättning Galera Cluster som använder synkron replikering (kolla den här bloggen Zero Downtime Network Migration With MySQL Galera Cluster Using Relay Node) eller genom att distribuera en asynkron MySQL/MariaDB-nod . I den här bloggen kommer vi att ställa in och distribuera hot standby-noden som replikerar asynkront från en av Galera-noderna.

Konfiguration av Galera Cluster

I den här exempelinställningen distribuerade vi kluster med tre noder med MariaDB 10.4.8-versionen. Detta kluster distribueras under USA:s östra region (Ohio) och topologin visas nedan:

Vi kommer att använda 172.31.26.175-servern som master för vår asynkrona slav som kommer att fungera som väntelägesnod.

Ställa in din EC2-instans för Hot Standby-nod

I AWS-konsolen, gå till EC2 som finns under avsnittet Beräkna och klicka på Starta instans för att skapa en EC2-instans precis som nedan.

Vi skapar den här instansen under regionen USA:s västra (Oregon). För din OS-typ kan du välja vilken server du gillar (jag föredrar Ubuntu 18.04) och välja typ av instans baserat på din föredragna måltyp. För det här exemplet kommer jag att använda t2.micro eftersom det inte kräver någon sofistikerad installation och det är bara för den här provinstallationen.

Som vi har nämnt tidigare är det bäst att din heta standby-nod är placerad i en annan region och inte samlokaliserad eller inom samma region. Så om det regionala datacentret går ner eller drabbas av ett nätverksavbrott, kan ditt hot standby-läge vara ditt failover-mål när det gick dåligt.

Innan vi fortsätter, i AWS, kommer olika regioner att ha sitt eget Virtual Private Cloud (VPC) och sitt eget nätverk. För att kunna kommunicera med Galera-klusternoderna måste vi först definiera en VPC-peering så att noderna kan kommunicera inom Amazonas infrastruktur och inte behöver gå utanför nätverket, vilket bara lägger till overhead- och säkerhetsproblem.

Gå först till din VPC där din heta standby-nod ska finnas och gå sedan till Peering Connections. Sedan måste du ange VPC för din standby-nod och Galera kluster VPC. I exemplet nedan har jag us-west-2 sammankopplad med us-east-2.

När du har skapat den ser du en post under dina Peering-anslutningar. Du måste dock acceptera begäran från Galera-klustret VPC, som finns på us-east-2 i det här exemplet. Se nedan,

När du har accepterat, glöm inte att lägga till CIDR i routingtabellen. Se den här externa bloggen VPC Peering om hur du gör det efter VPC Peering.

Nu, låt oss gå tillbaka och fortsätta skapa EC2-noden. Se till att din säkerhetsgrupp har rätt regler eller nödvändiga portar som måste öppnas. Se manualen för brandväggsinställningar för mer information om detta. För den här konfigurationen har jag bara ställt in All Traffic för att accepteras eftersom detta bara är ett test. Se nedan,

Se till att när du skapar din instans har du ställt in rätt VPC och att du har definierat ditt rätta subnät. Du kan kolla in den här bloggen om du behöver hjälp med det.

Konfigurera MariaDB Async-slaven

Steg ett

Först måste vi ställa in arkivet, lägga till arkivnycklarna och uppdatera paketlistan i arkivets cache,

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

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

$ apt update

Steg två

Installera MariaDB-paketen och dess obligatoriska binärer

$ 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

Steg tre

Låt oss nu ta en säkerhetskopia med hjälp av xbstream för att överföra filerna till nätverket från en av noderna i vårt Galera-kluster.

## Radera datakatalogen för den nyligen installerade MySQL i din heta standby-nod.

$ systemctl stop mariadb

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

## Sedan på hot standby-noden, kör detta på terminalen,

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

## Sedan på målmastern, det vill säga en av noderna i ditt Galera-kluster (som är noden 172.31.28.175 i det här exemplet), kör detta på terminalen,

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

där 172.32.31.2 är IP-adressen för värdstandbynoden.

Steg fyra

Förbered din MySQL-konfigurationsfil. Eftersom detta är i Ubuntu, redigerar jag filen i /etc/mysql/my.cnf och med följande exempel på my.cnf från vår ClusterControl-mall,

[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

Naturligtvis kan du ändra detta enligt dina inställningar och krav.

Steg fem

Förbered säkerhetskopian från steg #3, d.v.s. den avslutande säkerhetskopieringen som nu är i hot standby-noden genom att köra kommandot nedan,

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

Steg sex

Ställ in äganderätten till datakatalogen i hot standby-noden,

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

Steg sju

Starta nu MariaDB-instansen

$  systemctl start mariadb

Steg åtta

Sistligen måste vi ställa in den asynkrona replikeringen,

## Skapa replikeringsanvändaren på huvudnoden, dvs noden i Galera-klustret

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)

## Hämta GTID-slavpositionen från xtrabackup_binlog_info enligt följande,

$  cat /var/lib/mysql/xtrabackup_binlog_info

binlog.000002   71131632 1000-1000-120454

## Ställ sedan in slavreplikeringen enligt följande,

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;

## Kontrollera nu slavstatusen,

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)

Lägga till din Hot Standby-nod till ClusterControl

Om du använder ClusterControl är det enkelt att övervaka din databasservers tillstånd. För att lägga till detta som en slav, välj det Galera-nodkluster du har och gå sedan till valknappen som visas nedan för att lägga till replikeringsslav:

Klicka på Lägg till replikeringsslav och välj att lägga till en befintlig slav precis som nedan,

Vår topologi ser lovande ut.

Som du kanske märker fungerar vår nod 172.32.31.2 som vår hot standby noden har en annan CIDR som prefix som 172.32.% us-west-2 (Oregon) medan de andra noderna är på 172.31.% placerade på us-east-2 (Ohio). De är helt i olika regioner, så om nätverksfel uppstår på dina Galera-noder, kan du failover till din hot standby-nod.

Slutsats

Att bygga en Hot Standby på Amazon AWS är enkelt och okomplicerat. Allt du behöver är att bestämma dina kapacitetskrav och din nätverkstopologi, säkerhet och protokoll som behöver ställas in.

Att använda VPC Peering hjälper till att påskynda interkommunikation mellan olika regioner utan att gå till det offentliga internet, så anslutningen förblir inom Amazons nätverksinfrastruktur.

Att använda asynkron replikering med en slav är naturligtvis inte tillräckligt, men den här bloggen fungerar som grunden för hur du kan initiera detta. Du kan nu enkelt skapa ett annat kluster där den asynkrona slaven replikerar och skapa ytterligare en serie Galera-kluster som fungerar som dina Disaster Recovery-noder, eller så kan du också använda variabeln gmcast.segment i Galera för att replikera synkront precis som det vi har på den här bloggen.