Galera Cluster 4.0 pertama kali dirilis sebagai bagian dari MariaDB 10.4 dan ada banyak peningkatan signifikan dalam rilis versi ini. Fitur yang paling mengesankan dalam rilis ini adalah Replikasi Streaming yang dirancang untuk menangani masalah berikut.
- Masalah dengan transaksi lama
- Masalah dengan transaksi besar
- Masalah dengan hot-spot di tabel
Di blog sebelumnya, kami mendalami fitur Replikasi Streaming baru di blog seri dua bagian (Bagian 1 dan Bagian 2). Bagian dari fitur baru di Galera 4.0 ini adalah tabel sistem baru yang sangat berguna untuk query dan pengecekan node Galera Cluster dan juga log yang telah diproses di Streaming Replication.
Juga di blog sebelumnya, kami juga menunjukkan kepada Anda Cara Mudah untuk Menyebarkan Cluster MySQL Galera di AWS dan juga cara Menyebarkan Cluster MySQL Galera 4.0 ke Amazon AWS EC2.
Percona belum merilis GA untuk Percona XtraDB Cluster (PXC) 8.0 mereka karena beberapa fitur masih dalam pengembangan, seperti fungsi wsrep MySQL WSREP_SYNC_WAIT_UPTO_GTID yang tampaknya belum ada (setidaknya pada versi PXC 8.0.15-5-27dev.4.2). Namun, ketika PXC 8.0 akan dirilis, ia akan dikemas dengan fitur-fitur hebat seperti...
- Kluster tangguh yang ditingkatkan
- Kluster ramah cloud
- pengemasan yang lebih baik
- Dukungan enkripsi
- DDL atom
Sambil menunggu rilis PXC 8.0 GA, kami akan membahas di blog ini bagaimana Anda dapat membuat Hot Standby Node di Amazon AWS untuk Galera Cluster 4.0 menggunakan MariaDB.
Apa itu Siaga Panas?
Siaga panas adalah istilah umum dalam komputasi, terutama pada sistem yang sangat terdistribusi. Ini adalah metode untuk redundansi di mana satu sistem berjalan secara bersamaan dengan sistem utama yang identik. Ketika kegagalan terjadi pada node utama, hot standby segera mengambil alih menggantikan sistem utama. Data dicerminkan ke kedua sistem secara real time.
Untuk sistem database, server siaga panas biasanya node kedua setelah master utama yang berjalan pada sumber daya yang kuat (sama seperti master). Node sekunder ini harus stabil seperti master utama agar berfungsi dengan benar.
Ini juga berfungsi sebagai node pemulihan data jika master node atau seluruh cluster down. Node siaga panas akan menggantikan node atau cluster yang gagal sambil terus melayani permintaan dari klien.
Di Galera Cluster, semua server bagian dari cluster dapat berfungsi sebagai node siaga. Namun, jika wilayah atau seluruh cluster turun, bagaimana Anda bisa mengatasinya? Membuat node siaga di luar wilayah atau jaringan tertentu dari cluster Anda adalah salah satu opsi di sini.
Di bagian berikut, kami akan menunjukkan cara membuat node siaga di AWS EC2 menggunakan MariaDB.
Menyebarkan Hot Standby di Amazon AWS
Sebelumnya, kami telah menunjukkan kepada Anda bagaimana Anda dapat membuat Galera Cluster di AWS. Anda mungkin ingin membaca Menyebarkan MySQL Galera Cluster 4.0 ke Amazon AWS EC2 jika Anda baru menggunakan Galera 4.0.
Menyebarkan node siaga panas Anda dapat di kumpulan Galera Cluster lain yang menggunakan replikasi sinkron (lihat blog ini Zero Downtime Network Migration With MySQL Galera Cluster Using Relay Node) atau dengan menerapkan node MySQL/MariaDB asinkron . Di blog ini, kami akan menyiapkan dan menerapkan node siaga panas yang mereplikasi secara asinkron dari salah satu node Galera.
Pengaturan Cluster Galera
Dalam contoh penyiapan ini, kami menerapkan cluster 3-node menggunakan versi MariaDB 10.4.8. Cluster ini sedang digunakan di bawah wilayah AS Timur (Ohio) dan topologinya ditunjukkan di bawah ini:
Kami akan menggunakan server 172.31.26.175 sebagai master untuk budak asinkron kami yang akan berfungsi sebagai node siaga.
Menyiapkan Instans EC2 Anda untuk Hot Standby Node
Di konsol AWS, buka EC2 yang ada di bawah bagian Hitung dan klik Luncurkan Instans untuk membuat instans EC2 seperti di bawah ini.
Kami akan membuat instance ini di bawah wilayah AS Barat (Oregon). Untuk jenis OS Anda, Anda dapat memilih server apa yang Anda suka (saya lebih suka Ubuntu 18.04) dan memilih jenis instance berdasarkan jenis target pilihan Anda. Untuk contoh ini saya akan menggunakan t2.micro karena tidak memerlukan pengaturan yang rumit dan hanya untuk penerapan contoh ini.
Seperti yang telah kami sebutkan sebelumnya bahwa yang terbaik adalah node siaga panas Anda berada di wilayah yang berbeda dan tidak ditempatkan atau di dalam wilayah yang sama. Jadi, jika pusat data regional mati atau mengalami gangguan jaringan, hot standby Anda dapat menjadi target failover Anda saat keadaan menjadi buruk.
Sebelum kita melanjutkan, di AWS, wilayah yang berbeda akan memiliki Virtual Private Cloud (VPC) dan jaringannya sendiri. Untuk berkomunikasi dengan node cluster Galera, pertama-tama kita harus mendefinisikan Peering VPC sehingga node dapat berkomunikasi dalam infrastruktur Amazon dan tidak perlu keluar jaringan yang hanya menambah masalah overhead dan keamanan.
Pertama, pergi ke VPC Anda dari mana node siaga panas Anda akan berada, kemudian pergi ke Koneksi Peering. Kemudian Anda perlu menentukan VPC node siaga Anda dan VPC cluster Galera. Pada contoh di bawah, saya memiliki us-west-2 yang terhubung ke us-east-2.
Setelah dibuat, Anda akan melihat entri di bawah Koneksi Peering Anda. Namun, Anda harus menerima permintaan dari VPC cluster Galera, yang ada di us-east-2 dalam contoh ini. Lihat di bawah,
Setelah diterima, jangan lupa untuk menambahkan CIDR ke tabel perutean. Lihat blog eksternal ini VPC Peering tentang cara melakukannya setelah Peering VPC.
Sekarang, mari kembali dan lanjutkan membuat simpul EC2. Pastikan Grup Keamanan Anda memiliki aturan yang benar atau port wajib yang perlu dibuka. Periksa manual pengaturan firewall untuk informasi lebih lanjut tentang ini. Untuk penyiapan ini, saya baru saja menyetel Semua Lalu Lintas agar diterima karena ini hanya pengujian. Lihat di bawah,
Pastikan saat membuat instance, Anda telah menyetel VPC yang benar dan Anda telah menentukan subnet Anda yang tepat. Anda dapat memeriksa blog ini jika Anda memerlukan bantuan tentang itu.
Menyiapkan MariaDB Async Slave
Langkah Pertama
Pertama kita perlu menyiapkan repositori, menambahkan kunci repo dan memperbarui daftar paket di cache repositori,
$ vi /etc/apt/sources.list.d/mariadb.list
$ apt-key adv --recv-keys --keyserver hkp://keyserver.ubuntu.com:80 0xF1656F24C74CD1D8
$ apt updateLangkah Kedua
Instal paket MariaDB dan binari yang diperlukan
$ 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-commonLangkah Ketiga
Sekarang, mari kita backup menggunakan xbstream untuk mentransfer file ke jaringan dari salah satu node di Galera Cluster kita.
## Hapus datadir dari MySQL yang baru diinstal di node siaga panas Anda.
$ systemctl stop mariadb
$ rm -rf /var/lib/mysql/*## Kemudian pada node siaga panas, jalankan ini di terminal,
$ socat -u tcp-listen:9999,reuseaddr stdout 2>/tmp/netcat.log | mbstream -x -C /var/lib/mysql## Kemudian pada master target, yaitu salah satu node di Galera Cluster Anda (yaitu node 172.31.28.175 dalam contoh ini), jalankan ini di terminal,
$ mariabackup --backup --target-dir=/tmp --stream=xbstream | socat - TCP4:172.32.31.2:9999dengan 172.32.31.2 adalah IP dari node siaga host.
Langkah Empat
Siapkan file konfigurasi MySQL Anda. Karena ini di Ubuntu, saya mengedit file di /etc/mysql/my.cnf dan dengan contoh berikut my.cnf diambil dari template ClusterControl kami,
[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/mysqlTentu saja, Anda dapat mengubahnya sesuai dengan pengaturan dan persyaratan Anda.
Langkah Kelima
Siapkan backup dari langkah #3 yaitu menyelesaikan backup yang sekarang berada di hot standby node dengan menjalankan perintah di bawah ini,
$ mariabackup --prepare --target-dir=/var/lib/mysqlLangkah Enam
Setel kepemilikan datadir di node siaga panas,
$ chown -R mysql.mysql /var/lib/mysqlLangkah Tujuh
Sekarang, mulai instance MariaDB
$ systemctl start mariadbLangkah Delapan
Terakhir, kita perlu menyiapkan replikasi asinkron,
## Buat pengguna replikasi di master node, yaitu node di cluster 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)## Dapatkan posisi slave GTID dari xtrabackup_binlog_info sebagai berikut,
$ cat /var/lib/mysql/xtrabackup_binlog_info
binlog.000002 71131632 1000-1000-120454## Kemudian atur replikasi slave sebagai berikut,
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;## Sekarang, periksa status budak,
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)Menambahkan Hot Standby Node Anda ke ClusterControl
Jika Anda menggunakan ClusterControl, mudah untuk memantau kesehatan server database Anda. Untuk menambahkan ini sebagai budak, pilih kluster simpul Galera yang Anda miliki lalu buka tombol pilihan seperti yang ditunjukkan di bawah ini untuk Tambahkan Budak Replikasi:
Klik Add Replication Slave dan pilih tambah slave yang ada seperti di bawah ini,
Topologi kami terlihat menjanjikan.
Seperti yang mungkin Anda perhatikan, node kami 172.32.31.2 berfungsi sebagai hot standby kami node memiliki CIDR berbeda yang diawali dengan 172,32.% us-west-2 (Oregon) sedangkan node lainnya sebesar 172,31.% terletak di us-east-2 (Ohio). Mereka benar-benar berada di wilayah yang berbeda, jadi jika terjadi kegagalan jaringan pada node Galera Anda, Anda dapat melakukan failover ke node siaga panas Anda.
Kesimpulan
Membangun Hot Standby di Amazon AWS mudah dan langsung. Yang Anda butuhkan hanyalah menentukan persyaratan kapasitas dan topologi jaringan, keamanan, dan protokol yang perlu disiapkan.
Menggunakan Peering VPC membantu mempercepat komunikasi antar wilayah yang berbeda tanpa harus ke internet publik, sehingga koneksi tetap berada dalam infrastruktur jaringan Amazon.
Menggunakan replikasi asinkron dengan satu budak, tentu saja, tidak cukup, tetapi blog ini berfungsi sebagai dasar tentang bagaimana Anda dapat memulai ini. Sekarang Anda dapat dengan mudah membuat cluster lain tempat slave asinkron mereplikasi dan membuat rangkaian Galera Cluster lain yang berfungsi sebagai node Disaster Recovery Anda, atau Anda juga dapat menggunakan variabel gmcast.segment di Galera untuk mereplikasi secara sinkron seperti yang kami miliki di blog ini.
