Menjalankan Cluster MariaDB Galera Tanpa Alat Orkestrasi Kontainer:Bagian Satu

Alat orkestrasi container menyederhanakan pengoperasian sistem terdistribusi, dengan menerapkan dan menerapkan ulang container dan menangani setiap kegagalan yang terjadi. Seseorang mungkin perlu memindahkan aplikasi, misalnya, untuk menangani pembaruan, penskalaan, atau kegagalan host yang mendasarinya. Meskipun ini terdengar hebat, itu tidak selalu bekerja dengan baik dengan cluster database yang sangat konsisten seperti Galera. Anda tidak bisa begitu saja memindahkan node database, mereka bukan aplikasi stateless. Juga, urutan di mana Anda melakukan operasi pada sebuah cluster memiliki signifikansi yang tinggi. Misalnya, memulai ulang kluster Galera harus dimulai dari node paling canggih, atau Anda akan kehilangan data. Oleh karena itu, kami akan menunjukkan cara menjalankan Galera Cluster di Docker tanpa alat orkestrasi container, sehingga Anda memiliki kendali penuh.

Dalam posting blog ini, kita akan melihat cara menjalankan MariaDB Galera Cluster pada container Docker menggunakan image Docker standar pada beberapa host Docker, tanpa bantuan alat orkestrasi seperti Swarm atau Kubernetes. Pendekatan ini mirip dengan menjalankan Galera Cluster pada host standar, tetapi manajemen proses dikonfigurasi melalui Docker.

Sebelum kita melompat lebih jauh ke detail, kami menganggap Anda telah menginstal Docker, menonaktifkan SElinux/AppArmor dan membersihkan aturan di dalam iptables, firewalld atau ufw (mana pun yang Anda gunakan). Berikut adalah tiga host Docker khusus untuk cluster database kami:

host1.local - 192.168.55.161
host2.local - 192.168.55.162
host3.local - 192.168.55.163

Jaringan Multi-host

Pertama-tama, jaringan Docker default terikat ke host lokal. Docker Swarm memperkenalkan lapisan jaringan lain yang disebut jaringan overlay, yang memperluas internetworking kontainer ke beberapa host Docker dalam sebuah cluster yang disebut Swarm. Jauh sebelum integrasi ini terjadi, ada banyak plugin jaringan yang dikembangkan untuk mendukung ini - Flannel, Calico, Weave adalah beberapa di antaranya.

Di sini, kita akan menggunakan Weave sebagai plugin jaringan Docker untuk jaringan multi-host. Ini terutama karena kesederhanaannya untuk menginstal dan menjalankannya, dan dukungan untuk DNS resolver (wadah yang berjalan di bawah jaringan ini dapat menyelesaikan nama host satu sama lain). Ada dua cara untuk menjalankan Weave - systemd atau melalui Docker. Kita akan menginstalnya sebagai unit systemd, jadi itu independen dari daemon Docker (jika tidak, kita harus memulai Docker terlebih dahulu sebelum Weave diaktifkan).

Unduh dan instal Weave:

$ curl -L git.io/weave -o /usr/local/bin/weave$ chmod a+x /usr/local/bin/weave

Buat file unit systemd untuk Weave:

$ cat> /etc/systemd/system/weave.service <


  
 Tentukan alamat IP atau nama host rekan-rekan di dalam /etc/sysconfig/weave:
 $ echo 'PEERS="192.168.55.161 192.168.55.162 192.168.55.163"'> /etc/sysconfig/weave 
 
  
 Mulai dan aktifkan Weave saat boot:
 $ systemctl start weave$ systemctl enable weave

 
 Ulangi 4 langkah di atas pada semua host Docker. Verifikasi dengan perintah berikut setelah selesai:
 $ status menenun 
 
 Jumlah rekan adalah apa yang kita cari. Seharusnya 3:
  ... Rekan-rekan:3 (dengan 6 koneksi mapan) ... 
 Menjalankan Kluster Galera
 
 Sekarang jaringan sudah siap, saatnya untuk memecat wadah database kami dan membentuk sebuah cluster. Aturan dasarnya adalah:
  Penampung harus dibuat di bawah --net=weave untuk memiliki konektivitas multi-host.
 Port container yang perlu dipublikasikan adalah 3306, 4444, 4567, 4568.
 Gambar Docker harus mendukung Galera. Jika Anda ingin menggunakan Oracle MySQL, dapatkan versi Codership. Jika Anda ingin Percona, gunakan gambar ini sebagai gantinya. Dalam posting blog ini, kami menggunakan MariaDB.
 
 
 Alasan kami memilih MariaDB sebagai vendor cluster Galera adalah:
  Galera disematkan ke MariaDB, mulai dari MariaDB 10.1.
 Image MariaDB dikelola oleh tim Docker dan MariaDB.
 Salah satu gambar Docker paling populer di luar sana.
 
 
 Bootstrap Cluster Galera harus dilakukan secara berurutan. Pertama, node terbaru harus dimulai dengan "wsrep_cluster_address=gcomm://". Kemudian, mulai node yang tersisa dengan alamat lengkap yang terdiri dari semua node dalam cluster, misalnya, "wsrep_cluster_address=gcomm://node1,node2,node3". Untuk menyelesaikan langkah-langkah ini menggunakan container, kita harus melakukan beberapa langkah tambahan untuk memastikan semua container berjalan secara homogen. Jadi rencananya adalah:
  Kita harus memulai dengan 4 kontainer dalam urutan ini - mariadb0 (bootstrap), mariadb2, mariadb3, mariadb1.
 Container mariadb0 akan menggunakan datadir dan configdir yang sama dengan mariadb1.
 Gunakan mariadb0 di host1 untuk bootstrap pertama, lalu mulai mariadb2 di host2, mariadb3 di host3.
 Hapus mariadb0 di host1 untuk memberi jalan bagi mariadb1.
 Terakhir, mulai mariadb1 di host1.
 
 
 Pada akhirnya, Anda akan memiliki Galera Cluster tiga simpul (mariadb1, mariadb2, mariadb3). Kontainer pertama (mariadb0) adalah penampung sementara untuk tujuan bootstrap saja, menggunakan alamat cluster "gcomm://". Ini berbagi datadir dan configdir yang sama dengan mariadb1 dan akan dihapus setelah cluster terbentuk (mariadb2 dan mariadb3 sudah aktif) dan node disinkronkan.
 
 Secara default, Galera dimatikan di MariaDB dan perlu diaktifkan dengan tanda yang disebut wsrep_on (setel ke AKTIF) dan wsrep_provider (diatur ke jalur pustaka Galera) ditambah sejumlah parameter terkait Galera. Jadi, kita perlu mendefinisikan file konfigurasi khusus untuk wadah agar dapat mengonfigurasi Galera dengan benar.
 
 Mari kita mulai dengan wadah pertama, mariadb0. Buat file di bawah /containers/mariadb1/conf.d/my.cnf dan tambahkan baris berikut:
 2sdpre>$ mkdir -p /containers/mariadb1/conf.d$ cat /containers/mariadb1/conf.d/my.cnf[mysqld]default_storage_engine =InnoDBbinlog_format =ROWinnodb_flush_log_at_trx_commit =0innodb_otomatis_file_FS_innodb_flush_file_innodb_flush_dirnodb_flush_ # MariaDB>10.1.19 dan>10.2.3 sajawsrep_on =ONwsrep_provider =/usr/lib/galera/libgalera_smm.sowsrep_sst_method =xtrabackup-v2  
 Karena image tidak disertakan dengan MariaDB Backup (yang merupakan metode SST pilihan untuk MariaDB 10.1 dan MariaDB 10.2), kami akan tetap menggunakan xtrabackup-v2 untuk saat ini.
 
 Untuk melakukan bootstrap pertama untuk cluster, jalankan container bootstrap (mariadb0) pada host1 dengan "datadir" dan "conf.d" mariadb1:
 $ docker run -d \ --name mariadb0 \ --hostname mariadb0.weave.local \ --net weave \ --publish "3306" \ --publish "4444" \ --publish "4567 " \ --publish "4568" \ $(weave dns-args) \ --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \ --env MYSQL_USER=proxysql \ --env MYSQL_PASSWORD=proxysqlpassword \ -- volume /containers/mariadb1/datadir:/var/lib/mysql \ --volume /containers/mariadb1/conf.d:/etc/mysql/mariadb.conf.d \ mariadb:10.2.15 \ --wsrep_cluster_address=gcomm:// \ --wsrep_sst_auth="root:PM7%[email protected]^1" \ --wsrep_node_address=mariadb0.weave.local 
 
 Parameter yang digunakan pada perintah di atas adalah:
  --nama , membuat wadah bernama "mariadb0",
 --nama host , memberikan wadah sebuah hostname "mariadb0.weave.local",
 --net , menempatkan wadah di jaringan weave untuk dukungan jaringan multi-host,
 --publikasikan , mengekspos port 3306, 4444, 4567, 4568 pada wadah ke host,
 $(menenun dns-args) , mengonfigurasi resolver DNS untuk penampung ini. Perintah ini dapat diterjemahkan ke dalam Docker run sebagai "--dns=172.17.0.1 --dns-search=weave.local.",
 --env MYSQL_ROOT_PASSWORD , kata sandi root MySQL,
 --env MYSQL_USER , membuat pengguna "proxysql" untuk digunakan nanti dengan ProxySQL untuk perutean basis data,
 --env MYSQL_PASSWORD , kata sandi pengguna "proxysql",
 --volume /containers/mariadb1/datadir:/var/lib/mysql , buat /containers/mariadb1/datadir jika tidak ada dan petakan dengan /var/lib/mysql (MySQL datadir) container (untuk node bootstrap, ini dapat dilewati),
 --volume /containers/mariadb1/conf.d:/etc/mysql/mariadb.conf.d , mount file di bawah direktori /containers/mariadb1/conf.d dari Docker Host, ke dalam container di /etc/mysql/mariadb.conf.d.
 mariadb:10.2.15 , menggunakan gambar MariaDB 10.2.15 dari sini,
 --wsrep_cluster_address , String koneksi Galera untuk cluster. "gcomm://" berarti bootstrap. Untuk container lainnya, kami akan menggunakan alamat lengkap sebagai gantinya.
 --wsrep_sst_auth , string otentikasi untuk pengguna SST. Gunakan pengguna yang sama sebagai root,
 --wsrep_node_address , nama host node, dalam hal ini kita akan menggunakan FQDN yang disediakan oleh Weave.
 
 
 Wadah bootstrap berisi beberapa hal penting:
  Nama, nama host, dan wsrep_node_address adalah mariadb0, tetapi menggunakan volume mariadb1.
 Alamat cluster adalah "gcomm://"
 Ada dua parameter --env tambahan - MYSQL_USER dan MYSQL_PASSWORD. Parameter ini akan membuat pengguna tambahan untuk tujuan pemantauan proxysql kami.
 
 
 Verifikasi dengan perintah berikut:
 $ docker ps$ docker logs -f mariadb0 
 
 Setelah Anda melihat baris berikut, ini menunjukkan proses bootstrap selesai dan Galera aktif:
 30-05-2018 23:19:30 139816524539648 [Catatan] WSREP:Disinkronkan dengan grup, siap untuk koneksi 
 
 Buat direktori untuk memuat file konfigurasi khusus kami di host yang tersisa:
 $ mkdir -p /containers/mariadb2/conf.d # di host2$ mkdir -p /containers/mariadb3/conf.d # di host3 
 
 Kemudian, salin my.cnf yang telah kita buat untuk mariadb0 dan mariadb1 masing-masing ke mariadb2 dan mariadb3:
 $ scp /containers/mariadb1/conf.d/my.cnf /containers/mariadb2/conf.d/ # di host1$ scp /containers/mariadb1/conf.d/my.cnf /containers/mariadb3 /conf.d/ # pada host1 
 
 Selanjutnya, buat 2 wadah database lainnya (mariadb2 dan mariadb3) masing-masing di host2 dan host3:
 $ docker run -d \ --name ${NAME} \ --hostname ${NAME}.weave.local \ --net weave \ --publish "3306:3306" \ --publish " 4444" \ --publish "4567" \ --publish "4568" \ $(weave dns-args) \ --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \ --volume /containers/${ NAMA}/datadir:/var/lib/mysql \ --volume /containers/${NAME}/conf.d:/etc/mysql/mariadb.conf.d \ mariadb:10.2.15 \ --wsrep_cluster_address=gcomm://mariadb0.weave.local,mariadb1.weave.local,mariadb2.weave.local,mariadb3.weave.local \ --wsrep_sst_auth="root:PM7%[email protected]^1" \ --wsrep_node_address=${ NAMA}.weave.local 
 
 ** Ganti ${NAME} masing-masing dengan mariadb2 atau mariadb3.
 
 Namun, ada tangkapan. Skrip titik masuk memeriksa layanan mysqld di latar belakang setelah inisialisasi basis data dengan menggunakan pengguna root MySQL tanpa kata sandi. Karena Galera secara otomatis melakukan sinkronisasi melalui SST atau IST saat memulai, kata sandi pengguna root MySQL akan berubah, mencerminkan node bootstrap. Dengan demikian, Anda akan melihat kesalahan berikut selama pengaktifan pertama:
 018-05-30 23:27:13 140003794790144 [Peringatan] Akses ditolak untuk pengguna 'root'@'localhost' (menggunakan kata sandi:NO)Proses init MySQL sedang berlangsung…Proses init MySQL gagal. 
 
 Triknya adalah me-restart container yang gagal sekali lagi, karena kali ini, MySQL datadir akan dibuat (dalam percobaan pertama) dan akan melewati bagian inisialisasi database:
 $ docker start mariadb2 # di host2$ docker start mariadb3 # di host3 
 
 Setelah dimulai, verifikasi dengan melihat baris berikut:
 $ docker logs -f mariadb2…2018-05-30 23:28:39 139808069601024 [Note] WSREP:Disinkronkan dengan grup, siap untuk koneksi 
 
 Pada titik ini, ada 3 kontainer yang sedang berjalan, mariadb0, mariadb2 dan mariadb3. Perhatikan bahwa mariadb0 dimulai menggunakan perintah bootstrap (gcomm://), yang berarti jika penampung secara otomatis dimulai ulang oleh Docker di masa mendatang, penampung berpotensi terputus dengan komponen utama. Jadi, kita perlu menghapus wadah ini dan menggantinya dengan mariadb1, menggunakan string koneksi Galera yang sama dengan yang lain dan menggunakan datadir dan configdir yang sama dengan mariadb0.
 
 Pertama, hentikan mariadb0 dengan mengirimkan SIGTERM (untuk memastikan node akan dimatikan dengan baik):
 $ docker kill -s 15 mariadb0 
 
 Kemudian, mulai mariadb1 di host1 menggunakan perintah yang sama seperti mariadb2 atau mariadb3:
 $ docker run -d \ --name mariadb1 \ --hostname mariadb1.weave.local \ --net weave \ --publish "3306:3306" \ --publish "4444" \ --publish "4567" \ --publish "4568" \ $(weave dns-args) \ --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \ --volume /containers/mariadb1/datadir:/var/lib /mysql \ --volume /containers/mariadb1/conf.d:/etc/mysql/mariadb.conf.d \ mariadb:10.2.15 \ --wsrep_cluster_address=gcomm://mariadb0.weave.local,mariadb1.weave. local,mariadb2.weave.local,mariadb3.weave.local \ --wsrep_sst_auth="root:PM7%[email protected]^1" \ --wsrep_node_address=mariadb1.weave.local 
 
 Kali ini anda tidak perlu melakukan trik restart karena datadir MySQL sudah ada (dibuat oleh mariadb0). Setelah penampung dimulai, verifikasi ukuran cluster adalah 3, statusnya harus di Utama dan status lokal disinkronkan:
 $ docker exec -it mariadb3 mysql -uroot "-pPM7%[email protected]^1" -e 'pilih nama_variabel, nilai_variabel dari information_schema.global_status di mana nama_variabel di ("wsrep_cluster_size", "wsrep_local_state_comment", "wsrep_cluster_status", "wsrep_incoming_addresses")'+---------------------------+------------ -------------------------------------------------- -----------------+| nama_variabel | variabel_nilai |+-----------------------+------------------- -------------------------------------------------- ----------+| WSREP_CLUSTER_SIZE | 3 || WSREP_CLUSTER_STATUS | Utama || WSREP_INCOMING_ADDRESSES | mariadb1.weave.local:3306,mariadb3.weave.local:3306,mariadb2.weave.local:3306 || WSREP_LOCAL_STATE_COMMENT | Disinkronkan |+---------------------------+------------------- -------------------------------------------------- ----------+ 
 
 Pada titik ini, arsitektur kita terlihat seperti ini:
  
 Meskipun perintah run cukup panjang, ini menggambarkan karakteristik container dengan baik. Mungkin ide yang baik untuk membungkus perintah dalam skrip untuk menyederhanakan langkah-langkah eksekusi, atau gunakan file penulisan sebagai gantinya.
 Perutean Basis Data dengan ProxySQL
 
 Sekarang kami memiliki tiga wadah basis data yang berjalan. Satu-satunya cara untuk mengakses cluster sekarang adalah dengan mengakses port MySQL host Docker yang diterbitkan individu, yaitu 3306 (peta ke 3306 ke container). Jadi apa yang terjadi jika salah satu wadah database gagal? Anda harus secara manual melakukan failover koneksi klien ke node berikutnya yang tersedia. Bergantung pada konektor aplikasi, Anda juga dapat menentukan daftar node dan membiarkan konektor melakukan failover dan perutean kueri untuk Anda (Connector/J, PHP mysqlnd). Jika tidak, merupakan ide yang baik untuk menyatukan sumber daya database menjadi satu sumber daya, yang dapat disebut layanan.
 
 Di sinilah ProxySQL muncul. ProxySQL dapat bertindak sebagai router kueri, load balancing koneksi database mirip dengan apa yang "Layanan" di dunia Swarm atau Kubernetes. Kami telah membuat image ProxySQL Docker untuk tujuan ini dan akan mempertahankan image untuk setiap versi baru dengan upaya terbaik kami.
 
 Sebelum kita menjalankan container ProxySQL, kita harus menyiapkan file konfigurasi. Berikut ini adalah apa yang telah kami konfigurasikan untuk proxysql1. Kami membuat file konfigurasi khusus di bawah /containers/proxysql1/proxysql.cnf di host1:
 $ cat /containers/proxysql1/proxysql.cnfdatadir="/var/lib/proxysql"admin_variables={ admin_credentials="admin:admin" mysql_ifaces="0.0.0.0:6032" refresh_interval=2000}mysql_variables={ threads=4 max_connections=2048 default_query_delay=0 default_query_timeout=36000000 have_compress=true poll_timeout=2000 interfaces="0.0.0.0:6033;/tmp/proxysql.sock" default_schema="information_schema" stacksize=1048576 server_version="5.1.30" connect_timeout_server=10000 monitor_history=60000 monitor_connect_interval=2000000 monitor_ping_interval=2000000 ping_interval_server=10000 ping_timeout_server=200 perintah_stats=true session_sort=true monitor_username="proxysql" monitor_password="proxysqlpassword"}mysql_servers =( { address="marivea. =3306 , hostgroup=10, max_connections=100 }, { address="mariadb 2.weave.local" , port=3306 , hostgroup=10, max_connections=100 }, { address="mariadb3.weave.local" , port=3306 , hostgroup=10, max_connections=100 }, { address="mariadb1. weave.local" , port=3306 , hostgroup=20, max_connections=100 }, { address="mariadb2.weave.local" , port=3306 , hostgroup=20, max_connections=100 }, { address="mariadb3.weave. local" , port=3306 , hostgroup=20, max_connections=100 })mysql_users =( { username ="sbtest" , password ="password" , default_hostgroup =10 , aktif =1 })mysql_query_rules =( { rule_id=100 active=1 match_pattern="^SELECT .* FOR UPDATE" destination_hostgroup=10 apply=1 }, { rule_id=200 active=1 match_pattern="^SELECT .*" destination_hostgroup=20 apply=1 }, { rule_id=300 active=1 match_ pattern=".*" destination_hostgroup=10 apply=1 })scheduler =( { id =1 nama file ="/usr/share/proxysql/tools/proxysql_galera_checker.sh" aktif =1 interval_ms =2000 arg1 ="10" arg2 ="20" arg3 ="1" arg4 ="1" arg5 ="/var/lib/proxysql/proxysql_galera_checker.log" }) 
 
 Konfigurasi di atas akan:
  mengonfigurasi dua grup host, grup penulis tunggal dan multipenulis, seperti yang didefinisikan di bagian "server_mysql",
 kirim pembacaan ke semua node Galera (hostgroup 20) sementara operasi tulis akan dilakukan ke satu server Galera (hostgroup 10),
 jadwalkan proxysql_galera_checker.sh,
 gunakan monitor_username dan monitor_password sebagai kredensial pemantauan yang dibuat saat pertama kali kita mem-bootstrap cluster (mariadb0).
 
 
 Salin file konfigurasi ke host2, untuk redundansi ProxySQL:
 $ mkdir -p /containers/proxysql2/ # pada host2$ scp /containers/proxysql1/proxysql.cnf /container/proxysql2/ # pada host1 
 
 Kemudian, jalankan wadah ProxySQL pada host1 dan host2 masing-masing:
 $ docker run -d \ --name=${NAME} \ --publish 6033 \ --publish 6032 \ --restart selalu \ --net=weave \ $(weave dns-args) \ --hostname ${NAME}.weave.local \ -v /containers/${NAME}/proxysql.cnf:/etc/proxysql.cnf \ -v /containers/${NAME}/data:/var/lib/ proxysql \ somenines/proxysql 
 
 ** Ganti ${NAME} masing-masing dengan proxysql1 atau proxysql2.
 
 Kami menentukan --restart=always untuk membuatnya selalu tersedia terlepas dari status keluar, serta startup otomatis ketika daemon Docker dimulai. Ini akan memastikan wadah ProxySQL bertindak seperti daemon.
 
 Verifikasi status server MySQL yang dipantau oleh kedua instans ProxySQL (OFFLINE_SOFT diharapkan untuk grup host penulis tunggal):
 $ docker exec -it proxysql1 mysql -uadmin -padmin -h127.0.0.1 -P6032 -e 'pilih hostgroup_id,hostname,status dari mysql_servers'+------------ --+-----------------------+--------------+| hostgroup_id | nama host | status |+--------------+------------+--------- -----+| 10 | mariadb1.weave.local | ONLINE || 10 | mariadb2.weave.local | OFFLINE_LEMBUT || 10 | mariadb3.weave.local | OFFLINE_LEMBUT || 20 | mariadb1.weave.local | ONLINE || 20 | mariadb2.weave.local | ONLINE || 20 | mariadb3.weave.local | ONLINE |+--------------+------------+--------- -----+ 
 
 Pada titik ini, arsitektur kita terlihat seperti ini:
  
 Semua koneksi yang berasal dari 6033 (baik dari host1, host2 atau jaringan container) akan dimuat seimbang ke container database backend menggunakan ProxySQL. Jika Anda ingin mengakses server database individual, gunakan port 3306 dari host fisik. Tidak ada alamat IP virtual sebagai titik akhir tunggal yang dikonfigurasi untuk layanan ProxySQL, tetapi kita dapat memilikinya dengan menggunakan Keepalive, yang akan dijelaskan di bagian selanjutnya.
 Alamat IP Virtual dengan Keepalive
 
 Karena kami mengonfigurasi wadah ProxySQL untuk berjalan di host1 dan host2, kami akan menggunakan wadah Keepalive untuk mengikat host-host ini bersama-sama dan memberikan alamat IP virtual melalui jaringan host. Ini memungkinkan satu titik akhir untuk aplikasi atau klien terhubung ke lapisan penyeimbang beban yang didukung oleh ProxySQL.
 
 Seperti biasa, buat file konfigurasi khusus untuk layanan Keepalive kami. Berikut adalah isi dari /containers/keepalived1/keepalived.conf:
 vrrp_instance VI_DOCKER { antarmuka ens33 # antarmuka untuk memantau status MASTER virtual_router_id 52 # Tetapkan satu ID untuk prioritas rute ini 101 unicast_src_ip 192.168.55.161 unicast_peer { 192.168.55.162 } virtual_ipaddress { 192.168.55.160 # virtual IP} 
 
 Salin file konfigurasi ke host2 untuk contoh kedua:
 $ mkdir -p /containers/keepalived2/ # di host2$ scp /containers/keepalived1/keepalived.conf /container/keepalived2/ # di host1 
 
 Ubah prioritas dari 101 menjadi 100 di dalam file konfigurasi yang disalin di host2:
 $ sed -i 's/101/100/g' /containers/keepalived2/keepalived.conf 
 
 **Instance dengan prioritas lebih tinggi akan menyimpan alamat IP virtual (dalam hal ini adalah host1), hingga komunikasi VRRP terputus (jika host1 mati).
 
 Kemudian, jalankan perintah berikut pada host1 dan host2 masing-masing:
 $ docker run -d \ --name=${NAME} \ --cap-add=NET_ADMIN \ --net=host \ --restart=always \ --volume /containers/${NAME }/keepalived.conf:/usr/local/etc/keepalived/keepalived.conf \ osixia/keepalived:1.4.4 
 
 ** Ganti ${NAME} dengan keepalived1 dan keepalived2.
 
 Perintah run memberitahu Docker untuk:
  --nama , buat wadah dengan
 --cap-add=NET_ADMIN , tambahkan kemampuan Linux untuk lingkup admin jaringan
 --net=host , pasang penampung ke jaringan host. Ini akan memberikan alamat IP virtual pada antarmuka host, ens33
 --restart=selalu , selalu jalankan container,
 --volume=/containers/${NAME}/keepalived.conf:/usr/local/etc/keepalived/keepalived.conf , petakan file konfigurasi khusus untuk penggunaan container.
 
 
 Setelah kedua wadah dimulai, verifikasi keberadaan alamat IP virtual dengan melihat antarmuka jaringan fisik dari node MASTER:
 $ ip a | grep ens332:ens33: mtu 1500 qdisc pfifo_fast state UP qlen 1000 inet 192.168.55.161/24 brd 192.168.55.255 scope global ens33 inet 192.168.55.160/32 scope global ens33 
 
 Klien dan aplikasi sekarang dapat menggunakan alamat IP virtual, 192.168.55.160 untuk mengakses layanan database. Alamat IP virtual ini ada di host1 saat ini. Jika host1 turun, keepalived2 akan mengambil alih alamat IP dan memunculkannya di host2. Perhatikan bahwa konfigurasi untuk keepalive ini tidak memantau wadah ProxySQL. Itu hanya memonitor iklan VRRP dari rekan-rekan Keepalive.
 
 Pada titik ini, arsitektur kita terlihat seperti ini:
  Ringkasan
 
 Jadi, sekarang kami memiliki MariaDB Galera Cluster yang digawangi oleh layanan ProxySQL yang sangat tersedia, semuanya berjalan di container Docker.
 
 Di bagian kedua, kita akan melihat bagaimana mengelola pengaturan ini. Kita akan melihat bagaimana melakukan operasi seperti shutdown yang anggun, bootstrap, mendeteksi node paling canggih, failover, pemulihan, scaling up/down, upgrade, backup dan sebagainya. Kami juga akan membahas pro dan kontra dari pengaturan ini untuk layanan basis data berkerumun kami.
 
 Selamat berkemas!