MariaDB MaxScale Load Balancing di Docker:Manajemen:Bagian Kedua

Entri blog ini merupakan kelanjutan dari MariaDB MaxScale Load Balancing  di Docker:Deployment - Part1. Di bagian ini, kita akan lebih fokus pada operasi manajemen dengan kasus penggunaan tingkat lanjut seperti kontrol layanan, manajemen konfigurasi, pemrosesan kueri, keamanan, dan rekonsiliasi cluster. Langkah-langkah contoh dan instruksi yang ditampilkan dalam posting ini didasarkan pada lingkungan berjalan yang telah kami siapkan di bagian pertama dari seri blog ini.

Kontrol Layanan

Untuk MaxScale, memulai dan menghentikan wadah adalah satu-satunya cara untuk mengontrol layanan. Asalkan wadah telah dibuat, kita dapat menggunakan perintah berikut untuk mengelola layanan:

$ docker start maxscale
$ docker stop maxscale
$ docker restart maxscale

Berjalan tanpa Hak Istimewa Root

Wadah Docker secara default dijalankan dengan hak akses root dan begitu juga aplikasi yang berjalan di dalam wadah. Ini adalah perhatian utama lainnya dari perspektif keamanan karena peretas dapat memperoleh akses root ke host Docker dengan meretas aplikasi yang berjalan di dalam wadah.

Untuk menjalankan Docker sebagai pengguna non-root, Anda harus menambahkan pengguna Anda ke grup buruh pelabuhan. Pertama, buat grup buruh pelabuhan jika tidak ada:

$ sudo groupadd docker

Kemudian, tambahkan pengguna Anda ke grup buruh pelabuhan. Dalam contoh ini, pengguna kami adalah "gelandangan":

$ sudo usermod -aG docker vagrant

Logout dan login kembali agar keanggotaan grup Anda dievaluasi ulang (atau reboot jika tidak berhasil). Pada titik ini, Anda dapat menjalankan wadah MaxScale dengan perintah run standar (tidak perlu sudo) sebagai pengguna "gelandangan":

$ docker run -d \
--name maxscale-unprivileged \
-p 4006:4006 \
-p 4008:4008 \
-p 8989:8989 \
-v $PWD/maxscale.cnf:/etc/maxscale.cnf \
mariadb/maxscale

Proses MaxScale dijalankan oleh pengguna "maxscale" dan tidak memerlukan hak khusus hingga tingkat root. Oleh karena itu, menjalankan container dalam mode non-hak istimewa selalu merupakan cara terbaik jika Anda mengkhawatirkan keamanannya.

Manajemen Konfigurasi

Untuk wadah MaxScale mandiri, manajemen konfigurasi memerlukan modifikasi pada file konfigurasi yang dipetakan diikuti dengan memulai ulang wadah MaxScale. Namun, jika Anda menjalankan sebagai layanan Docker Swarm, konfigurasi baru harus dimuat ke dalam Swarm Configs sebagai versi baru, misalnya:

$ cat maxscale.cnf | docker config create maxscale_config_v2 -

Kemudian, perbarui layanan dengan menghapus konfigurasi lama (maxscale_config) dan tambahkan yang baru (maxscale_config_v2) ke target yang sama:

$ docker service update \
--config-rm maxscale_config \
--config-add source=maxscale_config_v2,target=/etc/maxscale.cnf \
maxscale-cluster

Docker Swarm kemudian akan menjadwalkan pemindahan kontainer dan mengganti prosedur satu kontainer pada satu waktu hingga persyaratan replika terpenuhi.

Upgrade dan Downgrade

Salah satu keuntungan menjalankan aplikasi Anda di Docker adalah prosedur upgrade dan downgrade yang sepele. Setiap container yang sedang berjalan didasarkan pada sebuah gambar, dan gambar ini dapat dengan mudah diubah dengan tag gambar. Untuk mendapatkan daftar gambar yang tersedia untuk MaxScale, lihat bagian Tag di Docker Hub. Contoh berikut menunjukkan proses untuk menurunkan versi MaxScale 2.3 ke satu versi minor sebelumnya, 2.2:

$ docker run -d \
--name maxscale \
-p 4006:4006 \
-p 4008:4008 \
-v $PWD/maxscale.cnf:/etc/maxscale.cnf \
mariadb/maxscale:2.3
$ docker rm -f maxscale
$ docker run -d \
--name maxscale \
-p 4006:4006 \
-p 4008:4008 \
-v $PWD/maxscale.cnf:/etc/maxscale.cnf \
mariadb/maxscale:2.2

Pastikan opsi konfigurasi kompatibel dengan versi yang ingin Anda jalankan. Misalnya, penurunan versi di atas akan gagal saat pertama kali dijalankan karena kesalahan berikut:

2019-06-19 05:29:04.301   error  : (check_config_objects): Unexpected parameter 'master_reconnection' for object 'rw-service' of type 'service', or 'true' is an invalid value for parameter 'master_reconnection'.
2019-06-19 05:29:04.301   error  : (check_config_objects): Unexpected parameter 'delayed_retry' for object 'rw-service' of type 'service', or 'true' is an invalid value for parameter 'delayed_retry'.
2019-06-19 05:29:04.301   error  : (check_config_objects): Unexpected parameter 'transaction_replay_max_size' for object 'rw-service' of type 'service', or '1Mi' is an invalid value for parameter 'transaction_replay_max_size'.
2019-06-19 05:29:04.302   error  : (check_config_objects): Unexpected parameter 'transaction_replay' for object 'rw-service' of type 'service', or 'true' is an invalid value for parameter 'transaction_replay'.
2019-06-19 05:29:04.302   error  : (check_config_objects): Unexpected parameter 'causal_reads_timeout' for object 'rw-service' of type 'service', or '10' is an invalid value for parameter 'causal_reads_timeout'.
2019-06-19 05:29:04.302   error  : (check_config_objects): Unexpected parameter 'causal_reads' for object 'rw-service' of type 'service', or 'true' is an invalid value for parameter 'causal_reads'.

Yang perlu kita lakukan adalah menghapus opsi konfigurasi yang tidak didukung seperti yang ditunjukkan di atas dalam file konfigurasi sebelum menurunkan versi image container:

• koneksi ulang_master
• coba lagi_tertunda
• transaction_replay
• causal_reads_timeout
• causal_reads

Akhirnya, mulai wadah lagi dan Anda harus baik. Upgrade versi untuk MaxScale bekerja dengan cara yang sama. Cukup ubah tag yang ingin Anda gunakan dan pergilah.

Filter Skala Maks

MaxScale menggunakan komponen yang disebut filter untuk memanipulasi atau memproses permintaan saat mereka melewatinya. Ada banyak filter yang dapat Anda gunakan, seperti yang tercantum di halaman ini, Filter MaxScale 2.3. Misalnya, kueri tertentu dapat masuk ke file jika cocok dengan kriteria atau Anda dapat menulis ulang kueri yang masuk sebelum mencapai server backend.

Untuk mengaktifkan filter, Anda harus menentukan bagian dan memasukkan nama definisi ke dalam definisi layanan yang sesuai, seperti yang ditunjukkan pada contoh di bawah.

Log Kueri Semua (QLA)

Seperti yang dijelaskan namanya, filter QLA mencatat semua kueri yang cocok dengan kumpulan aturan per sesi klien. Semua kueri akan dicatat dengan mengikuti format basis file.

Pertama, tentukan komponen dengan type=filter dan module=qlafilter:

## Query Log All (QLA) filter
## Filter module for MaxScale to log all query content on a per client session basis
[qla-sbtest-no-pk]
type		= filter
module		= qlafilter
filebase	= /tmp/sbtest
match		= select.*from.*
exclude		= where.*id.*
user		= sbtest

Kemudian tambahkan komponen filter ke layanan kami:

[rw-service]
...
filters        = qla-sbtest-no-pk
[rr-service]
...
filters        = qla-sbtest-no-pk

Ini juga merupakan ide yang baik untuk memetakan /tmp container dengan direktori sebenarnya di host Docker, jadi kita tidak perlu mengakses container untuk mengambil file log yang dihasilkan. Pertama, buat direktori dan berikan izin yang dapat ditulis secara global:

$ mkdir qla
$ chmod 777 qla

Karena kita perlu mengikat direktori di atas ke dalam wadah, kita harus menghentikan dan menghapus wadah yang sedang berjalan dan menjalankannya kembali dengan perintah berikut:

$ docker stop maxscale
$ docker run -d \
--name maxscale \
--restart always \
-p 4006:4006 \
-p 4008:4008 \
-p 8989:8989 \
-v $PWD/maxscale.cnf:/etc/maxscale.cnf \
-v $PWD/qla:/tmp \
mariadb/maxscale

Anda kemudian dapat mengambil konten kueri yang dicatat di dalam direktori qla:

$ cat qla/*
Date,[email protected],Query
2019-06-18 08:25:13,[email protected]::ffff:192.168.0.19,select * from sbtest.sbtest1

Penulisan Ulang Kueri

Penulisan ulang kueri adalah fitur yang, bergantung pada kueri yang dijalankan terhadap server database, memungkinkan dengan cepat untuk mengisolasi dan memperbaiki kueri bermasalah serta meningkatkan kinerja.

Penulisan ulang kueri dapat dilakukan melalui regexfilter. Filter ini dapat mencocokkan atau mengecualikan pernyataan masuk menggunakan ekspresi reguler dan menggantinya dengan pernyataan lain. Setiap aturan didefinisikan di bagiannya sendiri dan menyertakan nama bagian di layanan terkait untuk mengaktifkannya.

Filter berikut akan cocok dengan sejumlah perintah SHOW yang tidak ingin kami tampilkan ke klien hanya-baca:

## Rewrite query based on regex match and replace
[block-show-commands]
type            = filter
module          = regexfilter
options         = ignorecase
match           = ^show (variables|global variables|global status|status|processlist|full processlist).*
replace         = SELECT 'Not allowed'

Kemudian kita dapat menambahkan filter ke layanan yang ingin kita terapkan. Misalnya, semua koneksi hanya-baca harus difilter untuk hal di atas:

[rr-service]
...
filters        = qla-sbtest-no-pk | block-show-commands

Ingatlah bahwa beberapa filter dapat didefinisikan menggunakan sintaks yang mirip dengan pipa shell Linux "|" sintaksis. Mulai ulang penampung untuk menerapkan perubahan konfigurasi:

$ docker restart maxscale

Kami kemudian dapat memverifikasi dengan kueri berikut:

$ mysql -usbtest -p -h192.168.0.200 -P4006 -e 'SHOW VARIABLES LIKE "max_connections"'
+-------------+
| Not allowed |
+-------------+
| Not allowed |
+-------------+

Anda akan mendapatkan hasil seperti yang diharapkan.

Pemulihan Kluster

MaxScale 2.2.2 dan yang lebih baru mendukung replikasi MariaDB atau pemulihan cluster otomatis atau manual untuk kejadian berikut:

• kegagalan
• peralihan
• bergabung kembali
• reset-replikasi

Failover untuk cluster master-slave dapat dan sering kali harus diatur untuk diaktifkan secara otomatis. Switchover harus diaktifkan secara manual melalui MaxAdmin, MaxCtrl atau antarmuka REST. Rejoin dapat diatur ke otomatis atau diaktifkan secara manual. Fitur-fitur ini diimplementasikan dalam modul "mariadbmon".

Peristiwa failover otomatis berikut terjadi jika kita dengan sengaja mematikan master aktif, 192.168.0.91:

$ docker logs -f maxscale
...
2019-06-19 03:53:02.348   error  : (mon_log_connect_error): Monitor was unable to connect to server mariadb1[192.168.0.91:3306] : 'Can't connect to MySQL server on '192.168.0.91' (115)'
2019-06-19 03:53:02.351   notice : (mon_log_state_change): Server changed state: mariadb1[192.168.0.91:3306]: master_down. [Master, Running] -> [Down]
2019-06-19 03:53:02.351   warning: (handle_auto_failover): Master has failed. If master status does not change in 4 monitor passes, failover begins.
2019-06-19 03:53:16.710   notice : (select_promotion_target): Selecting a server to promote and replace 'mariadb1'. Candidates are: 'mariadb2', 'mariadb3'.
2019-06-19 03:53:16.710   warning: (warn_replication_settings): Slave 'mariadb2' has gtid_strict_mode disabled. Enabling this setting is recommended. For more information, see https://mariadb.com/kb/en/library/gtid/#gtid_strict_mode
2019-06-19 03:53:16.711   warning: (warn_replication_settings): Slave 'mariadb3' has gtid_strict_mode disabled. Enabling this setting is recommended. For more information, see https://mariadb.com/kb/en/library/gtid/#gtid_strict_mode
2019-06-19 03:53:16.711   notice : (select_promotion_target): Selected 'mariadb2'.
2019-06-19 03:53:16.711   notice : (handle_auto_failover): Performing automatic failover to replace failed master 'mariadb1'.
2019-06-19 03:53:16.723   notice : (redirect_slaves_ex): Redirecting 'mariadb3' to replicate from 'mariadb2' instead of 'mariadb1'.
2019-06-19 03:53:16.742   notice : (redirect_slaves_ex): All redirects successful.
2019-06-19 03:53:17.249   notice : (wait_cluster_stabilization): All redirected slaves successfully started replication from 'mariadb2'.
2019-06-19 03:53:17.249   notice : (handle_auto_failover): Failover 'mariadb1' -> 'mariadb2' performed.
2019-06-19 03:53:20.363   notice : (mon_log_state_change): Server changed state: mariadb2[192.168.0.92:3306]: new_master. [Slave, Running] -> [Master, Running]

Setelah failover selesai, topologi kita sekarang terlihat seperti ini:

Untuk pengoperasian switchover, diperlukan campur tangan manusia dan salah satu caranya adalah melalui konsol MaxCtrl. Katakanlah master lama sudah kembali beroperasi dan siap dipromosikan sebagai master, kita dapat melakukan operasi peralihan dengan mengirimkan perintah berikut:

$ docker exec -it maxscale maxctrl
maxctrl: call command mariadbmon switchover monitor mariadb1 mariadb2
OK

Dimana, formatnya adalah:

$ call command <monitoring module> <operation> <monitoring section name> <new master> <current master>

Kemudian, verifikasi topologi baru dengan membuat daftar server:

 maxctrl: list servers
┌──────────┬──────────────┬──────┬─────────────┬─────────────────┬──────────────┐
│ Server   │ Address      │ Port │ Connections │ State           │ GTID         │
├──────────┼──────────────┼──────┼─────────────┼─────────────────┼──────────────┤
│ mariadb1 │ 192.168.0.91 │ 3306 │ 0           │ Master, Running │ 0-5001-12144 │
├──────────┼──────────────┼──────┼─────────────┼─────────────────┼──────────────┤
│ mariadb2 │ 192.168.0.92 │ 3306 │ 0           │ Slave, Running  │ 0-5001-12144 │
├──────────┼──────────────┼──────┼─────────────┼─────────────────┼──────────────┤
│ mariadb3 │ 192.168.0.93 │ 3306 │ 0           │ Slave, Running  │ 0-5001-12144 │
└──────────┴──────────────┴──────┴─────────────┴─────────────────┴──────────────┘

Kami baru saja mempromosikan tuan lama kami kembali ke tempat asalnya. Fakta menyenangkan, fitur pemulihan otomatis ClusterControl melakukan hal yang persis sama jika diaktifkan.

Pemikiran Terakhir

Menjalankan MariaDB MaxScale di Docker memberikan manfaat tambahan seperti pengelompokan MaxScale, peningkatan dan penurunan versi yang mudah, dan juga fungsionalitas proksi tingkat lanjut untuk klaster MySQL dan MariaDB.