Menjalankan Cluster MariaDB Galera Tanpa Alat Orkestrasi - Manajemen Kontainer DB:Bagian Kedua

Seperti yang kita lihat di bagian pertama blog ini, cluster database yang sangat konsisten seperti Galera tidak cocok dengan alat orkestrasi container seperti Kubernetes atau Swarm. Kami menunjukkan kepada Anda cara menerapkan Galera dan mengonfigurasi manajemen proses untuk Docker, sehingga Anda tetap memegang kendali penuh atas perilaku tersebut. Posting blog ini adalah kelanjutan dari itu, kami akan melihat operasi dan pemeliharaan cluster.

Untuk merangkum beberapa poin utama dari bagian 1 blog ini, kami menerapkan cluster Galera tiga node, dengan ProxySQL dan Keepalive pada tiga host Docker yang berbeda, di mana semua instance MariaDB dijalankan sebagai container Docker. Diagram berikut mengilustrasikan penerapan akhir:

Penonaktifan dengan Anggun

Untuk melakukan shutdown MySQL dengan baik, cara terbaik adalah mengirim SIGTERM (sinyal 15) ke container:

$ docker kill -s 15 {db_container_name}

Jika Anda ingin mematikan kluster, ulangi perintah di atas pada semua wadah basis data, satu simpul pada satu waktu. Di atas mirip dengan melakukan "systemctl stop mysql" di layanan systemd untuk MariaDB. Menggunakan perintah "docker stop" cukup berisiko untuk layanan database karena menunggu 10 detik timeout dan Docker akan memaksa SIGKILL jika durasi ini terlampaui (kecuali jika Anda menggunakan --timeout yang tepat nilai).

Node terakhir yang dimatikan dengan baik akan memiliki seqno tidak sama dengan -1 dan safe_to_bootstrap flag disetel ke 1 di /{datadir volume}/grastate.dat dari host Docker, misalnya pada host2:

$ cat /containers/mariadb2/datadir/grastate.dat
# GALERA saved state
version: 2.1
uuid:    e70b7437-645f-11e8-9f44-5b204e58220b
seqno:   7099
safe_to_bootstrap: 1

Mendeteksi Node Tercanggih

Jika cluster tidak dimatikan dengan baik, atau node yang Anda coba bootstrap bukan node terakhir yang meninggalkan cluster, Anda mungkin tidak akan dapat mem-bootstrap salah satu node Galera dan mungkin mengalami kesalahan berikut :

2016-11-07 01:49:19 5572 [ERROR] WSREP: It may not be safe to bootstrap the cluster from this node.
It was not the last one to leave the cluster and may not contain all the updates.
To force cluster bootstrap with this node, edit the grastate.dat file manually and set safe_to_bootstrap to 1 .

Galera menghormati node yang memiliki safe_to_bootstrap flag diatur ke 1 sebagai node referensi pertama. Ini adalah cara teraman untuk menghindari kehilangan data dan memastikan node yang benar selalu di-bootstrap.

Jika Anda mendapatkan kesalahan, kita harus mencari tahu node yang paling canggih terlebih dahulu sebelum mengambil node sebagai yang pertama di-bootstrap. Buat wadah sementara (dengan --rm flag), petakan ke direktori datadir dan konfigurasi yang sama dari wadah database aktual dengan dua flag perintah MySQL, --wsrep_recover dan --wsrep_cluster_address . Misalnya, jika kita ingin mengetahui nomor terakhir yang dikomit mariadb1, kita perlu menjalankan:

$ docker run --rm --name mariadb-recover \
        --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
        --volume /containers/mariadb1/datadir:/var/lib/mysql \
        --volume /containers/mariadb1/conf.d:/etc/mysql/conf.d \
        mariadb:10.2.15 \
        --wsrep_recover \
        --wsrep_cluster_address=gcomm://
2018-06-12  4:46:35 139993094592384 [Note] mysqld (mysqld 10.2.15-MariaDB-10.2.15+maria~jessie) starting as process 1 ...
2018-06-12  4:46:35 139993094592384 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
...
2018-06-12  4:46:35 139993094592384 [Note] Plugin 'FEEDBACK' is disabled.
2018-06-12  4:46:35 139993094592384 [Note] Server socket created on IP: '::'.
2018-06-12  4:46:35 139993094592384 [Note] WSREP: Recovered position: e70b7437-645f-11e8-9f44-5b204e58220b:7099

Baris terakhir adalah apa yang kita cari. MariaDB mencetak kluster UUID dan nomor urut transaksi yang paling baru dilakukan. Node yang memegang angka tertinggi dianggap sebagai node paling maju. Karena kami menentukan --rm , wadah akan dihapus secara otomatis setelah keluar. Ulangi langkah di atas pada setiap host Docker dengan mengganti --volume jalur ke volume wadah basis data masing-masing.

Setelah Anda membandingkan nilai yang dilaporkan oleh semua wadah basis data dan memutuskan wadah mana yang merupakan simpul paling mutakhir, ubah safe_to_bootstrap tandai ke 1 di dalam /{datadir volume}/grastate.dat secara manual. Katakanlah semua node melaporkan nomor urut yang sama persis, kita bisa memilih mariadb3 untuk di-bootstrap dengan mengubah safe_to_bootstrap nilai ke 1:

$ vim /containers/mariadb3/datadir/grasate.dat
...
safe_to_bootstrap: 1

Simpan file dan mulai bootstrap cluster dari node itu, seperti yang dijelaskan di bab berikutnya.

Bootstrap Cluster

Bootstrap cluster mirip dengan perintah docker run pertama yang kami gunakan saat memulai cluster untuk pertama kalinya. Jika mariadb1 adalah node bootstrap yang dipilih, kita cukup menjalankan kembali container bootstrap yang telah dibuat:

$ docker start mariadb0 # on host1

Jika tidak, jika wadah bootstrap tidak ada di simpul yang dipilih, katakanlah di host2, jalankan perintah wadah bootstrap dan petakan volume mariadb2 yang ada. Kami menggunakan mariadb0 sebagai nama wadah di host2 untuk menunjukkan bahwa itu adalah wadah bootstrap:

$ 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" \
        --volume /containers/mariadb2/datadir:/var/lib/mysql \
        --volume /containers/mariadb2/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

Anda mungkin memperhatikan bahwa perintah ini sedikit lebih pendek dibandingkan dengan perintah bootstrap sebelumnya yang dijelaskan dalam panduan ini. Karena kita sudah memiliki pengguna proxysql yang dibuat di perintah bootstrap pertama kita, kita dapat melewatkan dua variabel lingkungan ini:

--env MYSQL_USER=proxysql
--env MYSQL_PASSWORD=proxysqlpassword

Kemudian, mulai wadah MariaDB yang tersisa, hapus wadah bootstrap dan mulai wadah MariaDB yang ada di host bootstrap. Pada dasarnya urutan perintahnya adalah:

$ docker start mariadb1 # on host1
$ docker start mariadb3 # on host3
$ docker stop mariadb0 # on host2
$ docker start mariadb2 # on host2

Pada titik ini, cluster dimulai dan berjalan dengan kapasitas penuh.

Kontrol Sumber Daya

Memori adalah sumber daya yang sangat penting di MySQL. Di sinilah buffer dan cache disimpan, dan sangat penting bagi MySQL untuk mengurangi dampak terlalu sering memukul disk. Di sisi lain, swapping buruk untuk kinerja MySQL. Secara default, tidak akan ada batasan sumber daya pada container yang sedang berjalan. Kontainer menggunakan sumber daya yang diberikan sebanyak yang diizinkan oleh kernel host. Hal penting lainnya adalah batas deskriptor file. Anda dapat meningkatkan batas deskriptor file terbuka, atau "nofile" ke sesuatu yang lebih tinggi untuk memenuhi jumlah file yang dapat dibuka server MySQL secara bersamaan. Menyetel ini ke nilai tinggi tidak ada salahnya.

Untuk membatasi alokasi memori dan meningkatkan batas deskriptor file ke wadah basis data kami, seseorang akan menambahkan --memory , --memory-swap dan --ulimit parameter ke dalam perintah "docker run":

$ docker kill -s 15 mariadb1
$ docker rm -f mariadb1
$ docker run -d \
        --name mariadb1 \
        --hostname mariadb1.weave.local \
        --net weave \
        --publish "3306:3306" \
        --publish "4444" \
        --publish "4567" \
        --publish "4568" \
        $(weave dns-args) \
        --memory 16g \
        --memory-swap 16g \
        --ulimit nofile:16000:16000 \
        --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

Perhatikan bahwa jika --memory-swap disetel ke nilai yang sama dengan --memory , dan --memori diatur ke bilangan bulat positif, wadah tidak akan memiliki akses ke swap. Jika --memory-swap tidak disetel, pertukaran kontainer akan menjadi default --memory kalikan dengan 2. Jika --memori dan --memory-swap diatur ke nilai yang sama, ini akan mencegah kontainer menggunakan swap apa pun. Ini karena --memory-swap adalah jumlah gabungan memori dan swap yang dapat digunakan, sedangkan --memori hanya jumlah memori fisik yang dapat digunakan.

Beberapa sumber daya container seperti memori dan CPU dapat dikontrol secara dinamis melalui perintah "docker update", seperti yang ditunjukkan pada contoh berikut untuk meningkatkan memori container mariadb1 ke 32G secara langsung:

$ docker update \
    --memory 32g \
    --memory-swap 32g \
    mariadb1

Jangan lupa untuk menyetel my.cnf agar sesuai dengan spesifikasi baru. Manajemen konfigurasi dijelaskan di bagian berikutnya.

Manajemen Konfigurasi

Sebagian besar parameter konfigurasi MySQL/MariaDB dapat diubah selama runtime, yang berarti Anda tidak perlu memulai ulang untuk menerapkan perubahan. Lihat halaman dokumentasi MariaDB untuk detailnya. Parameter yang terdaftar dengan "Dinamis:Ya" berarti variabel dimuat segera setelah diubah tanpa perlu me-restart server MariaDB. Jika tidak, atur parameter di dalam file konfigurasi khusus di host Docker. Misalnya, pada mariadb3, buat perubahan pada file berikut:

$ vim /containers/mariadb3/conf.d/my.cnf

Dan kemudian restart wadah database untuk menerapkan perubahan:

$ docker restart mariadb3

Verifikasi wadah memulai proses dengan melihat log buruh pelabuhan. Lakukan operasi ini pada satu node pada satu waktu jika Anda ingin membuat perubahan di seluruh cluster.

Cadangan

Mengambil cadangan logis cukup mudah karena gambar MariaDB juga dilengkapi dengan biner mysqldump. Anda cukup menggunakan perintah "docker exec" untuk menjalankan mysqldump dan mengirim output ke file relatif ke jalur host. Perintah berikut melakukan pencadangan mysqldump di mariadb2 dan menyimpannya ke /backups/mariadb2 di dalam host2:

$ docker exec -it mariadb2 mysqldump -uroot -p --single-transaction > /backups/mariadb2/dump.sql

Pencadangan biner seperti Percona Xtrabackup atau Cadangan MariaDB memerlukan proses untuk mengakses direktori data MariaDB secara langsung. Anda harus menginstal alat ini di dalam wadah, atau melalui host mesin atau menggunakan gambar khusus untuk tujuan ini seperti gambar "perconalab/percona-xtrabackup" untuk membuat cadangan dan menyimpannya di dalam /tmp/backup di Host Docker:

$ docker run --rm -it \
    -v /containers/mariadb2/datadir:/var/lib/mysql \
    -v /tmp/backup:/xtrabackup_backupfiles \
    perconalab/percona-xtrabackup \
    --backup --host=mariadb2 --user=root --password=mypassword

Anda juga dapat menghentikan penampung dengan innodb_fast_shutdown setel ke 0 dan salin volume datadir ke lokasi lain di host fisik:

$ docker exec -it mariadb2 mysql -uroot -p -e 'SET GLOBAL innodb_fast_shutdown = 0'
$ docker kill -s 15 mariadb2
$ cp -Rf /containers/mariadb2/datadir /backups/mariadb2/datadir_copied
$ docker start mariadb2

Pulihkan

Memulihkan cukup mudah untuk mysqldump. Anda cukup mengarahkan stdin ke wadah dari host fisik:

$ docker exec -it mariadb2 mysql -uroot -p < /backups/mariadb2/dump.sql

Anda juga dapat menggunakan baris perintah klien mysql standar dari jarak jauh dengan nama host dan nilai port yang tepat daripada menggunakan perintah "docker exec" ini:

$ mysql -uroot -p -h127.0.0.1 -P3306 < /backups/mariadb2/dump.sql

Untuk Percona Xtrabackup dan MariaDB Backup, kita harus menyiapkan backup terlebih dahulu. Ini akan meneruskan pencadangan ke waktu ketika pencadangan selesai. Katakanlah file Xtrabackup kita berada di bawah /tmp/backup dari host Docker, untuk mempersiapkannya, cukup:

$ docker run --rm -it \
    -v mysql-datadir:/var/lib/mysql \
    -v /tmp/backup:/xtrabackup_backupfiles \
    perconalab/percona-xtrabackup \
    --prepare --target-dir /xtrabackup_backupfiles

Cadangan yang disiapkan di bawah /tmp/backup dari host Docker kemudian dapat digunakan sebagai direktori data MariaDB untuk wadah atau klaster baru. Katakanlah kita hanya ingin memverifikasi pemulihan pada wadah MariaDB mandiri, kita akan menjalankan:

$ docker run -d \
    --name mariadb-restored \
    --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
    -v /tmp/backup:/var/lib/mysql \
    mariadb:10.2.15

Jika Anda melakukan pencadangan menggunakan pendekatan berhenti dan salin, Anda cukup menduplikasi direktori data dan menggunakan direktori duplikat sebagai peta volume ke direktori data MariaDB untuk dijalankan di wadah lain. Katakanlah cadangan disalin di bawah /backups/mariadb2/datadir_copied, kita dapat menjalankan wadah baru dengan menjalankan:

$ mkdir -p /containers/mariadb-restored/datadir
$ cp -Rf /backups/mariadb2/datadir_copied /containers/mariadb-restored/datadir
$ docker run -d \
    --name mariadb-restored \
    --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
    -v /containers/mariadb-restored/datadir:/var/lib/mysql \
    mariadb:10.2.15

MYSQL_ROOT_PASSWORD harus cocok dengan kata sandi root yang sebenarnya untuk cadangan tertentu.

Beberapa MySQL di Docker:Cara Menampung Basis Data Anda Temukan semua yang perlu Anda pahami saat mempertimbangkan untuk menjalankan layanan MySQL di atas virtualisasi penampung DockerUnduh Whitepaper

Peningkatan Versi Basis Data

Ada dua jenis pemutakhiran - pemutakhiran di tempat atau pemutakhiran logis.

Pemutakhiran di tempat melibatkan mematikan server MariaDB, mengganti binari lama dengan binari baru dan kemudian memulai server pada direktori data lama. Setelah dimulai, Anda harus menjalankan mysql_upgrade skrip untuk memeriksa dan meningkatkan semua tabel sistem dan juga untuk memeriksa tabel pengguna.

Pembaruan logis melibatkan mengekspor SQL dari versi saat ini menggunakan utilitas cadangan logis seperti mysqldump, menjalankan wadah baru dengan binari versi yang ditingkatkan, dan kemudian menerapkan SQL ke versi MySQL/MariaDB baru. Ini mirip dengan pendekatan pencadangan dan pemulihan yang dijelaskan di bagian sebelumnya.

Namun demikian, ini adalah pendekatan yang baik untuk selalu membuat cadangan database Anda sebelum melakukan operasi yang merusak. Langkah-langkah berikut diperlukan saat memutakhirkan dari gambar saat ini, MariaDB 10.1.33 ke versi utama lainnya, MariaDB 10.2.15 di mariadb3 berada di host3:

Cadangkan databasenya. Tidak masalah pencadangan fisik atau logis tetapi yang terakhir menggunakan mysqldump disarankan.
Unduh gambar terbaru yang ingin kami tingkatkan ke:
```
$ docker pull mariadb:10.2.15
```

Setel innodb_fast_shutdown ke 0 untuk wadah basis data kami:

$ docker exec -it mariadb3 mysql -uroot -p -e 'SET GLOBAL innodb_fast_shutdown = 0'

Dengan anggun mematikan wadah basis data:
```
$ docker kill --signal=TERM mariadb3
```

Buat wadah baru dengan gambar baru untuk wadah database kami. Jaga agar parameter lainnya tetap utuh kecuali menggunakan nama penampung baru (jika tidak, akan bentrok):

$ docker run -d \
        --name mariadb3-new \
        --hostname mariadb3.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/mariadb3/datadir:/var/lib/mysql \
        --volume /containers/mariadb3/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=mariadb3.weave.local

Jalankan skrip mysql_upgrade:

$ docker exec -it mariadb3-new mysql_upgrade -uroot -p

Jika tidak terjadi kesalahan, hapus penampung lama, mariadb3 (yang baru mariadb3-baru):
```
$ docker rm -f mariadb3
```
Jika tidak, jika proses pemutakhiran gagal di antaranya, kita dapat kembali ke penampung sebelumnya:
```
$ docker stop mariadb3-new
$ docker start mariadb3
```

Upgrade versi mayor dapat dilakukan mirip dengan upgrade versi minor, kecuali Anda harus ingat bahwa MySQL/MariaDB hanya mendukung upgrade mayor dari versi sebelumnya. Jika Anda menggunakan MariaDB 10.0 dan ingin meningkatkan ke 10.2, Anda harus meningkatkan ke MariaDB 10.1 terlebih dahulu, diikuti dengan langkah peningkatan lainnya ke MariaDB 10.2.

Perhatikan perubahan konfigurasi yang diperkenalkan dan tidak digunakan lagi di antara versi utama.

Kegagalan

Di Galera, semua node adalah master dan memegang peran yang sama. Dengan ProxySQL pada gambar, koneksi yang melewati gateway ini akan gagal secara otomatis selama ada komponen utama yang berjalan untuk Galera Cluster (yaitu, sebagian besar node aktif). Aplikasi tidak akan melihat perbedaan apa pun jika satu node database mati karena ProxySQL hanya akan mengarahkan ulang koneksi ke node lain yang tersedia.

Jika aplikasi terhubung langsung ke MariaDB melewati ProxySQL, failover harus dilakukan di sisi aplikasi dengan menunjuk ke node berikutnya yang tersedia, asalkan node database memenuhi ketentuan berikut:

Status wsrep_local_state_comment Disinkronkan (Status "Tidak Disinkronkan/Donor" juga dimungkinkan, hanya jika wsrep_sst_method adalah xtrabackup, xtrabackup-v2 atau mariabackup).
Status wsrep_cluster_status adalah Pratama.

Di Galera, node yang tersedia tidak berarti node tersebut sehat hingga status di atas diverifikasi.

Meningkatkan Skala

Untuk menskalakan, kita dapat membuat wadah baru di jaringan yang sama dan menggunakan file konfigurasi khusus yang sama untuk wadah yang ada di host tertentu. Sebagai contoh, katakanlah kita ingin menambahkan wadah MariaDB keempat di host3, kita dapat menggunakan file konfigurasi yang sama yang dipasang untuk mariadb3, seperti yang diilustrasikan pada diagram berikut:

Jalankan perintah berikut pada host3 untuk memperkecil:

$ docker run -d \
        --name mariadb4 \
        --hostname mariadb4.weave.local \
        --net weave \
        --publish "3306:3307" \
        --publish "4444" \
        --publish "4567" \
        --publish "4568" \
        $(weave dns-args) \
        --env MYSQL_ROOT_PASSWORD="PM7%[email protected]^1" \
        --volume /containers/mariadb4/datadir:/var/lib/mysql \
        --volume /containers/mariadb3/conf.d:/etc/mysql/mariadb.conf.d \
        mariadb:10.2.15 \
        --wsrep_cluster_address=gcomm://mariadb1.weave.local,mariadb2.weave.local,mariadb3.weave.local,mariadb4.weave.local \
        --wsrep_sst_auth="root:PM7%[email protected]^1" \
        --wsrep_node_address=mariadb4.weave.local

Setelah container dibuat, container tersebut akan bergabung dengan cluster dan melakukan SST. Itu dapat diakses di port 3307 secara eksternal atau di luar jaringan Weave, atau port 3306 di dalam host atau di dalam jaringan Weave. Tidak perlu lagi menyertakan mariadb0.weave.local ke dalam alamat cluster. Setelah kluster diskalakan, kita perlu menambahkan wadah MariaDB baru ke dalam set penyeimbangan beban ProxySQL melalui konsol admin:

$ docker exec -it proxysql1 mysql -uadmin -padmin -P6032
mysql> INSERT INTO mysql_servers(hostgroup_id,hostname,port) VALUES (10,'mariadb4.weave.local',3306);
mysql> INSERT INTO mysql_servers(hostgroup_id,hostname,port) VALUES (20,'mariadb4.weave.local',3306);
mysql> LOAD MYSQL SERVERS TO RUNTIME;
mysql> SAVE MYSQL SERVERS TO DISK;

Ulangi perintah di atas pada instance ProxySQL kedua.

Terakhir untuk langkah terakhir, (Anda dapat melewati bagian ini jika Anda sudah menjalankan pernyataan "SAVE .. TO DISK" di ProxySQL), tambahkan baris berikut ke proxysql.cnf untuk membuatnya tetap di seluruh container restart pada host1 dan host2:

$ vim /containers/proxysql1/proxysql.cnf # host1
$ vim /containers/proxysql2/proxysql.cnf # host2

Dan tambahkan baris terkait mariadb4 di bawah arahan mysql_server:

mysql_servers =
(
        { address="mariadb1.weave.local" , port=3306 , hostgroup=10, max_connections=100 },
        { address="mariadb2.weave.local" , port=3306 , hostgroup=10, max_connections=100 },
        { address="mariadb3.weave.local" , port=3306 , hostgroup=10, max_connections=100 },
        { address="mariadb4.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 },
        { address="mariadb4.weave.local" , port=3306 , hostgroup=20, max_connections=100 }
)

Simpan file dan kita akan baik-baik saja di container berikutnya.

Menurunkan

Untuk memperkecil, cukup matikan wadah dengan anggun. Perintah terbaiknya adalah:

$ docker kill -s 15 mariadb4
$ docker rm -f mariadb4

Ingat, jika simpul basis data meninggalkan klaster secara tidak wajar, itu bukan bagian dari penskalaan dan akan memengaruhi penghitungan kuorum.

Untuk menghapus wadah dari ProxySQL, jalankan perintah berikut di kedua wadah ProxySQL. Misalnya, pada proxysql1:

$ docker exec -it proxysql1 mysql -uadmin -padmin -P6032
mysql> DELETE FROM mysql_servers WHERE hostname="mariadb4.weave.local";
mysql> LOAD MYSQL SERVERS TO RUNTIME;
mysql> SAVE MYSQL SERVERS TO DISK;

Anda kemudian dapat menghapus entri yang sesuai di dalam proxysql.cnf atau membiarkannya seperti itu. Ini akan dideteksi sebagai OFFLINE dari sudut pandang ProxySQL.

Ringkasan

Dengan Docker, segalanya menjadi sedikit berbeda dari cara konvensional dalam menangani server MySQL atau MariaDB. Menangani layanan stateful seperti Galera Cluster tidak semudah aplikasi stateless, dan membutuhkan pengujian dan perencanaan yang tepat.

Di blog berikutnya tentang topik ini, kami akan mengevaluasi pro dan kontra menjalankan Galera Cluster di Docker tanpa alat orkestrasi apa pun.