MariaDB
 sql >> Datenbank >  >> RDS >> MariaDB

Erstellen eines Hot Standby auf Amazon AWS mit MariaDB-Cluster

Galera Cluster 4.0 wurde erstmals als Teil von MariaDB 10.4 veröffentlicht und es gibt viele signifikante Verbesserungen in dieser Versionsfreigabe. Das beeindruckendste Feature in dieser Version ist die Streaming-Replikation, die die folgenden Probleme handhaben soll.

  • Probleme mit langen Transaktionen
  • Probleme mit großen Transaktionen
  • Probleme mit Hotspots in Tabellen

In einem früheren Blog haben wir uns in einer zweiteiligen Blogserie (Teil 1 und Teil 2) eingehend mit der neuen Streaming-Replikationsfunktion befasst. Teil dieser neuen Funktion in Galera 4.0 sind neue Systemtabellen, die sehr nützlich sind, um die Galera-Cluster-Knoten abzufragen und zu überprüfen, sowie die Protokolle, die in der Streaming-Replikation verarbeitet wurden.

Auch in früheren Blogs haben wir Ihnen gezeigt, wie Sie einen MySQL Galera-Cluster auf AWS einfach bereitstellen und wie Sie einen MySQL Galera-Cluster 4.0 auf Amazon AWS EC2 bereitstellen.

Percona hat noch keine GA für ihren Percona XtraDB Cluster (PXC) 8.0 veröffentlicht, da sich einige Funktionen noch in der Entwicklung befinden, wie die MySQL-wsrep-Funktion WSREP_SYNC_WAIT_UPTO_GTID, die noch nicht vorhanden zu sein scheint (zumindest auf PXC 8.0.15-5-27dev.4.2-Version). Doch wenn PXC 8.0 veröffentlicht wird, wird es vollgepackt sein mit großartigen Funktionen wie...

  • Verbesserter belastbarer Cluster
  • Cloud-freundlicher Cluster
  • verbesserte Verpackung
  • Verschlüsselungsunterstützung
  • Atomic DDL

Während wir auf die Veröffentlichung von PXC 8.0 GA warten, behandeln wir in diesem Blog, wie Sie mit MariaDB einen Hot-Standby-Knoten auf Amazon AWS für Galera Cluster 4.0 erstellen können.

Was ist Hot Standby?

Hot Standby ist ein geläufiger Begriff in der Computertechnik, insbesondere auf stark verteilten Systemen. Es ist eine Redundanzmethode, bei der ein System gleichzeitig mit einem identischen Primärsystem läuft. Wenn der primäre Knoten ausfällt, übernimmt Hot Standby sofort den Austausch des primären Systems. Daten werden in Echtzeit auf beide Systeme gespiegelt.

Für Datenbanksysteme ist ein Hot-Standby-Server normalerweise der zweite Knoten nach dem primären Master, der auf leistungsstarken Ressourcen (wie der Master) läuft. Dieser sekundäre Knoten muss so stabil sein wie der primäre Master, um korrekt zu funktionieren.

Er dient auch als Datenwiederherstellungsknoten, wenn der Masterknoten oder der gesamte Cluster ausfällt. Der Hot-Standby-Knoten ersetzt den ausgefallenen Knoten oder Cluster, während er die Nachfrage der Clients kontinuierlich bedient.

Im Galera-Cluster können alle Server, die Teil des Clusters sind, als Standby-Knoten dienen. Wenn jedoch die Region oder der gesamte Cluster ausfällt, wie werden Sie in der Lage sein, damit fertig zu werden? Das Erstellen eines Standby-Knotens außerhalb der spezifischen Region oder des Netzwerks Ihres Clusters ist hier eine Option.

Im folgenden Abschnitt zeigen wir Ihnen, wie Sie mit MariaDB einen Standby-Knoten auf AWS EC2 erstellen.

Bereitstellen eines Hot Standby auf Amazon AWS

Zuvor haben wir Ihnen gezeigt, wie Sie einen Galera-Cluster auf AWS erstellen können. Falls Sie neu bei Galera 4.0 sind, sollten Sie den Artikel Deploying MySQL Galera Cluster 4.0 on Amazon AWS EC2 lesen.

Die Bereitstellung Ihres Hot-Standby-Knotens kann auf einem anderen Satz von Galera-Clustern erfolgen, die synchrone Replikation verwenden (lesen Sie diesen Blog Zero Downtime Network Migration With MySQL Galera Cluster Using Relay Node) oder durch Bereitstellung eines asynchronen MySQL/MariaDB-Knotens . In diesem Blog werden wir den Hot-Standby-Knoten einrichten und bereitstellen, der asynchron von einem der Galera-Knoten repliziert.

Das Galera-Cluster-Setup

In diesem Beispiel-Setup haben wir einen 3-Knoten-Cluster mit der MariaDB-Version 10.4.8 bereitgestellt. Dieser Cluster wird in der Region USA Ost (Ohio) bereitgestellt und die Topologie ist unten dargestellt:

Wir verwenden den 172.31.26.175-Server als Master für unseren asynchronen Slave der als Standby-Knoten dienen wird.

Einrichten Ihrer EC2-Instanz für Hot-Standby-Knoten

Gehen Sie in der AWS-Konsole zu EC2 im Abschnitt „Compute“ und klicken Sie auf „Launch Instance“, um eine EC2-Instance wie unten zu erstellen.

Wir erstellen diese Instanz unter der Region USA West (Oregon). Für Ihren Betriebssystemtyp können Sie den gewünschten Server auswählen (ich bevorzuge Ubuntu 18.04) und den Instanztyp basierend auf Ihrem bevorzugten Zieltyp auswählen. Für dieses Beispiel werde ich t2.micro verwenden, da es keine ausgefeilte Einrichtung erfordert und nur für diese Beispielbereitstellung geeignet ist.

Wie wir bereits erwähnt haben, ist es am besten, wenn sich Ihr Hot-Standby-Knoten in einer anderen Region und nicht in derselben Region befindet. Falls also das regionale Rechenzentrum ausfällt oder einen Netzwerkausfall erleidet, kann Ihr Hot-Standby Ihr Failover-Ziel sein, wenn etwas schief geht.

Bevor wir fortfahren, werden in AWS verschiedene Regionen ihre eigene Virtual Private Cloud (VPC) und ihr eigenes Netzwerk haben. Um mit den Galera-Clusterknoten zu kommunizieren, müssen wir zunächst ein VPC-Peering definieren, damit die Knoten innerhalb der Amazon-Infrastruktur kommunizieren können und nicht das Netzwerk verlassen müssen, was nur Overhead und Sicherheitsbedenken hinzufügt.

Gehen Sie zuerst zu Ihrer VPC, von der aus sich Ihr Hot-Standby-Knoten befinden soll, und gehen Sie dann zu Peering-Verbindungen. Dann müssen Sie die VPC Ihres Standby-Knotens und die Galera-Cluster-VPC angeben. Im Beispiel unten habe ich us-west-2 mit us-east-2 verbunden.

Nach der Erstellung sehen Sie einen Eintrag unter Ihren Peering-Verbindungen. Sie müssen jedoch die Anfrage von der Galera-Cluster-VPC akzeptieren, die sich in diesem Beispiel auf us-east-2 befindet. Siehe unten,

Vergessen Sie nach der Annahme nicht, die CIDR zur Routingtabelle hinzuzufügen. In diesem externen Blog VPC-Peering erfahren Sie, wie es nach dem VPC-Peering funktioniert.

Nun gehen wir zurück und fahren mit der Erstellung des EC2-Knotens fort. Stellen Sie sicher, dass Ihre Sicherheitsgruppe über die richtigen Regeln oder erforderlichen Ports verfügt, die geöffnet werden müssen. Weitere Informationen hierzu finden Sie im Handbuch zu den Firewall-Einstellungen. Für diese Einrichtung habe ich nur "Alle Zugriffe" so eingestellt, dass sie akzeptiert werden, da dies nur ein Test ist. Siehe unten,

Stellen Sie beim Erstellen Ihrer Instanz sicher, dass Sie die richtige VPC und Sie eingestellt haben Ihr richtiges Subnetz definiert haben. Sie können in diesem Blog nachsehen, falls Sie diesbezüglich Hilfe benötigen.

Einrichten des MariaDB Async Slave

Schritt Eins

Zuerst müssen wir das Repository einrichten, die Repo-Schlüssel hinzufügen und die Paketliste im Repository-Cache aktualisieren,

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

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

$ apt update

Schritt Zwei

Installieren Sie die MariaDB-Pakete und die erforderlichen Binärdateien

$ 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

Schritt Drei

Lassen Sie uns nun ein Backup mit xbstream erstellen, um die Dateien von einem der Knoten in unserem Galera-Cluster auf das Netzwerk zu übertragen.

## Löschen Sie das Datenverzeichnis des neu installierten MySQL in Ihrem Hot-Standby-Knoten.

$ systemctl stop mariadb

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

## Führen Sie dies dann auf dem Hot-Standby-Knoten auf dem Terminal aus,

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

## Führen Sie dann auf dem Ziel-Master, d. h. einem der Knoten in Ihrem Galera-Cluster (in diesem Beispiel der Knoten 172.31.28.175), dies auf dem Terminal aus,

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

wobei 172.32.31.2 die IP des Host-Standby-Knotens ist.

Schritt Vier

Bereiten Sie Ihre MySQL-Konfigurationsdatei vor. Da dies in Ubuntu ist, bearbeite ich die Datei in /etc/mysql/my.cnf und mit dem folgenden Beispiel my.cnf aus unserer ClusterControl-Vorlage,

[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

Natürlich können Sie dies entsprechend Ihrem Setup und Ihren Anforderungen ändern.

Schritt Fünf

Bereiten Sie die Sicherung aus Schritt 3 vor, d. h. die fertige Sicherung, die sich jetzt im Hot-Standby-Knoten befindet, indem Sie den folgenden Befehl ausführen,

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

Schritt Sechs

Legen Sie den Besitz des Datenverzeichnisses im Hot-Standby-Knoten fest,

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

Schritt sieben

Starten Sie jetzt die MariaDB-Instanz

$  systemctl start mariadb

Achter Schritt

Zuletzt müssen wir die asynchrone Replikation einrichten,

## Erstellen Sie den Replikationsbenutzer auf dem Masterknoten, d. h. dem Knoten im 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)

## Erhalten Sie die GTID-Slave-Position von xtrabackup_binlog_info wie folgt,

$  cat /var/lib/mysql/xtrabackup_binlog_info

binlog.000002   71131632 1000-1000-120454

##  Richten Sie dann die Slave-Replikation wie folgt ein,

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;

## Überprüfen Sie nun den 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)

Hinzufügen Ihres Hot-Standby-Knotens zu ClusterControl

Wenn Sie ClusterControl verwenden, ist es einfach, den Zustand Ihres Datenbankservers zu überwachen. Um dies als Slave hinzuzufügen, wählen Sie das Galera-Node-Cluster aus, das Sie haben, und gehen Sie dann wie unten gezeigt auf die Auswahlschaltfläche, um Replikations-Slave hinzuzufügen:

Klicken Sie auf Replikations-Slave hinzufügen und wählen Sie das Hinzufügen eines vorhandenen Slaves wie unten beschrieben aus

Unsere Topologie sieht vielversprechend aus.

Wie Sie vielleicht bemerkt haben, dient unser Knoten 172.32.31.2 als Hot-Standby Knoten hat eine andere CIDR mit dem Präfix 172,32 % us-west-2 (Oregon), während sich die anderen Knoten zu 172,31 % auf us-east-2 (Ohio) befinden. Sie befinden sich vollständig in einer anderen Region, sodass Sie im Falle eines Netzwerkausfalls auf Ihren Galera-Knoten ein Failover auf Ihren Hot-Standby-Knoten durchführen können.

Fazit

Der Aufbau eines Hot Standby auf Amazon AWS ist einfach und unkompliziert. Sie müssen lediglich Ihre Kapazitätsanforderungen und Ihre Netzwerktopologie, Sicherheit und Protokolle, die eingerichtet werden müssen, bestimmen.

Die Verwendung von VPC-Peering hilft, die Kommunikation zwischen verschiedenen Regionen zu beschleunigen, ohne auf das öffentliche Internet zu gehen, sodass die Verbindung innerhalb der Amazon-Netzwerkinfrastruktur bleibt.

Die Verwendung der asynchronen Replikation mit einem Slave reicht natürlich nicht aus, aber dieser Blog dient als Grundlage dafür, wie Sie dies initiieren können. Sie können jetzt einfach einen weiteren Cluster erstellen, in dem der asynchrone Slave repliziert, und eine weitere Reihe von Galera-Clustern erstellen, die als Ihre Disaster Recovery-Knoten dienen, oder Sie können auch die gmcast.segment-Variable in Galera verwenden, um synchron zu replizieren, genau wie in diesem Blog.