Apa yang Baru di MariaDB MaxScale 2.4

MaxScale 2.4 dirilis pada 21 Desember 2019, dan ClusterControl 1.7.6 mendukung pemantauan dan pengelolaan hingga versi ini. Namun, untuk penerapan, ClusterControl hanya mendukung hingga versi 2.3. Seseorang harus memutakhirkan instance secara manual, dan untungnya, langkah-langkah pemutakhiran sangat mudah. Cukup unduh versi terbaru dari halaman unduh MariaDB MaxScale dan lakukan perintah instalasi paket.

Perintah berikut menunjukkan cara meningkatkan dari MaxScale 2.3 yang ada ke MaxScale 2.4 pada kotak CentOS 7:

$ wget https://dlm.mariadb.com/1067184/MaxScale/2.4.10/centos/7/x86_64/maxscale-2.4.10-1.centos.7.x86_64.rpm
$ systemctl stop maxscale
$ yum localinstall -y maxscale-2.4.10-1.centos.7.x86_64.rpm
$ systemctl start maxscale
$ maxscale --version
MaxScale 2.4.10

Dalam posting blog ini, kami akan menyoroti beberapa peningkatan penting dan fitur baru dari versi ini dan bagaimana tampilannya dalam tindakan. Untuk daftar lengkap perubahan di MariaDB MaxScale 2.4, lihat log perubahannya.

Riwayat Perintah Mode Interaktif

Ini pada dasarnya adalah peningkatan kecil dengan dampak besar pada administrasi MaxScale dan efisiensi tugas pemantauan. Mode interaktif untuk MaxCtrl sekarang memiliki riwayat perintahnya. Riwayat perintah dengan mudah memungkinkan Anda untuk mengulangi perintah yang dijalankan dengan menekan tombol panah atas atau bawah. Namun, fungsionalitas Ctrl+R (ingat perintah terakhir yang cocok dengan karakter yang Anda berikan) masih belum ada.

Di versi sebelumnya, kita harus menggunakan mode shell standar untuk memastikan perintah ditangkap oleh file .bash_history.

Pemantauan GTID untuk galeramon

Ini adalah peningkatan yang bagus untuk mereka yang menjalankan Galera Cluster dengan redundansi geografis melalui replikasi asinkron, juga dikenal sebagai replikasi cluster-to-cluster, atau replikasi MariaDB Galera Cluster melalui MariaDB Replication.

Di MaxScale 2.3 dan yang lebih lama, seperti inilah tampilannya jika Anda telah mengaktifkan replikasi master-slave antara Cluster MariaDB:

Untuk MaxScale 2.4, sekarang terlihat seperti ini (perhatikan Galera1's baris):

Sekarang lebih mudah untuk melihat status replikasi untuk semua node dari MaxScale, tanpa kebutuhan untuk memeriksa setiap node berulang kali.

SmartRouter

Ini adalah salah satu fitur utama baru di MaxScale 2.4, di mana MaxScale sekarang cukup pintar untuk mempelajari server backend MariaDB backend mana yang terbaik untuk memproses kueri. SmartRouter melacak kinerja, atau waktu eksekusi, kueri ke cluster. Pengukuran disimpan dengan kanonik kueri sebagai kuncinya. Kanonik kueri adalah SQL dengan semua konstanta yang ditentukan pengguna diganti dengan tanda tanya, misalnya:

UPDATE `money_in` SET `accountholdername` = ? , `modifiedon` = ? , `status` = ? , `modifiedby` = ? WHERE `id` = ? 

Ini adalah fitur yang sangat berguna jika Anda menjalankan MariaDB pada replikasi geografis multi-situs atau campuran mesin penyimpanan MariaDB dalam satu rantai replikasi, misalnya, slave khusus untuk menangani beban kerja transaksi (OLTP ) dengan mesin penyimpanan InnoDB dan budak khusus lainnya untuk menangani beban kerja analitik (OLAP) dengan mesin penyimpanan Columnstore.

Misalkan kita memiliki dua situs - Sydney dan Singapura seperti yang diilustrasikan pada diagram berikut:

Situs utama terletak di Singapura dan memiliki master dan budak MariaDB , sementara slave read-only lainnya berada di Sydney. Aplikasi terhubung ke instance MaxScale yang terletak di negaranya masing-masing dengan pengaturan port berikut:

• Pembagian baca-tulis:3306
• Ground robin:3307
• Router pintar:3308

Definisi layanan dan pendengar SmarRouter kami adalah:

[SmartQuery]
type=service
router=smartrouter
servers=DB_1,DB_2,DB_5
master=DB_1
user=maxscale
password=******

[SmartQuery-Listener]
type = listener
service = SmartQuery
protocol = mariadbclient
port = 3308

Mulai ulang MaxScale dan mulai mengirimkan kueri hanya-baca ke node MaxScale yang berlokasi di Singapura dan Sydney. Jika kueri diproses oleh router round-robin (port 3307), kita akan melihat kueri dirutekan berdasarkan algoritma round-robin:

(app)$ mysql -usbtest -p -h maxscale_sydney -P3307 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+--------------------+
| count(id) | @@hostname         |
+-----------+--------------------+
|   1000000 | mariadb_singapore2 |
+-----------+--------------------+

Dari atas, kami dapat mengetahui bahwa MaxScale Sydney meneruskan kueri di atas ke slave kami di Singapura, yang sebenarnya bukan merupakan opsi perutean terbaik.

Dengan SmartRouter mendengarkan pada port 3308, kita akan melihat kueri sedang dirutekan ke slave terdekat di Sydney:

(app)$ mysql -usbtest -p -h maxscale_sydney -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+-----------------+
| count(id) | @@hostname      |
+-----------+-----------------+
|   1000000 | mariadb_sydney1 |
+-----------+-----------------+

Dan jika kueri yang sama dijalankan di situs kami di Singapura, kueri tersebut akan dirutekan ke budak MariaDB yang terletak di Singapura:

(app)$ mysql -usbtest -p -h maxscale_singapore -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+--------------------+
| count(id) | @@hostname         |
+-----------+--------------------+
|   1000000 | mariadb_singapore2 |
+-----------+--------------------+

Namun, ada tangkapan. Saat SmartRouter melihat kueri baca yang kanoniknya belum pernah dilihat sebelumnya, ia akan mengirim kueri ke semua cluster. Respons pertama dari sebuah cluster akan menunjuk cluster tersebut sebagai yang terbaik untuk kanonik tersebut. Juga, ketika respons pertama diterima, kueri lainnya dibatalkan. Respons dikirim ke klien setelah semua cluster merespons permintaan atau pembatalan.

Ini berarti, untuk melacak kueri kanonik (kueri yang dinormalisasi) dan mengukur kinerjanya, Anda mungkin akan melihat kueri pertama gagal dalam eksekusi pertamanya, misalnya:

(app)$ mysql -usbtest -p -h maxscale_sydney -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
ERROR 2013 (HY000) at line 1: Lost connection to MySQL server during query

Dari log umum di MariaDB Sydney, kami dapat mengetahui bahwa kueri pertama (ID 74) berhasil dijalankan (sambungkan, kueri, dan keluar), meskipun ada kesalahan "Koneksi terputus" dari MaxScale:

  74 Connect  [email protected] as anonymous on 
  74 Query    SELECT COUNT(id),@@hostname FROM sbtest.sbtest1
  74 Quit

Sementara kueri berikutnya yang identik diproses dengan benar dan dikembalikan dengan respons yang benar:

(app)$ mysql -usbtest -p -h maxscale_sydney -P3308 -e 'SELECT COUNT(id),@@hostname FROM sbtest.sbtest1'
+-----------+------------------------+
| count(id) | @@hostname             |
+-----------+------------------------+
|   1000000 | mariadb_sydney.cluster |
+-----------+------------------------+

Melihat kembali log umum di MariaDB Sydney (ID 75), peristiwa pemrosesan yang sama terjadi seperti kueri pertama:

  75 Connect  [email protected] as anonymous on 
  75 Query    SELECT COUNT(id),@@hostname FROM sbtest.sbtest1
  75 Quit

Dari pengamatan ini, kita dapat menyimpulkan bahwa kadang-kadang, MaxScale harus gagal pada kueri pertama untuk mengukur kinerja dan menjadi lebih pintar untuk kueri identik berikutnya. Aplikasi Anda harus dapat menangani "kesalahan pertama" ini dengan benar sebelum kembali ke klien atau mencoba lagi transaksi tersebut.

Soket UNIX untuk Server

Ada beberapa cara untuk terhubung ke server MySQL atau MariaDB yang sedang berjalan. Anda dapat menggunakan jaringan standar TCP/IP dengan alamat IP host dan port (koneksi jarak jauh), bernama pipa/memori bersama pada Windows atau file soket Unix pada sistem berbasis Unix. File soket UNIX adalah jenis file khusus yang memfasilitasi komunikasi antara proses yang berbeda, yang dalam hal ini adalah klien MySQL dan server. File soket adalah komunikasi berbasis file, dan Anda tidak dapat mengakses soket dari komputer lain. Ini menyediakan koneksi yang lebih cepat daripada TCP/IP (tanpa overhead jaringan) dan pendekatan koneksi yang lebih aman karena hanya dapat digunakan saat menghubungkan ke layanan atau proses di komputer yang sama.

Seharusnya server MaxScale juga diinstal pada Server MariaDB itu sendiri, kita dapat menggunakan file socket UNIX socket sebagai gantinya. Di bawah bagian Server, hapus atau komentari baris "alamat" dan tambahkan parameter soket dengan lokasi file soket:

[DB_2]
type=server
protocol=mariadbbackend
#address=54.255.133.39
socket=/var/lib/mysql/mysql.sock

Sebelum menerapkan perubahan di atas, kita harus membuat pengguna skala sumbu MaxScale dari localhost. Di server utama:

MariaDB> CREATE USER 'maxscale'@'localhost' IDENTIFIED BY 'maxscalep4ss';
MariaDB> GRANT SELECT ON mysql.user TO 'maxscale'@'localhost';
MariaDB> GRANT SELECT ON mysql.db TO 'maxscale'@'localhost';
MariaDB> GRANT SELECT ON mysql.tables_priv TO 'maxscale'@'localhost';
MariaDB> GRANT SHOW DATABASES ON *.* TO 'maxscale'@'localhost';

Setelah restart, MaxScale akan menampilkan jalur soket UNIX alih-alih alamat sebenarnya, dan daftar server akan ditampilkan seperti ini:

Seperti yang Anda lihat, informasi status dan GTID diambil dengan benar melalui koneksi soket. Perhatikan bahwa DB_2 ini masih mendengarkan port 3306 untuk koneksi jarak jauh. Itu hanya menunjukkan bahwa MaxScale menggunakan soket untuk terhubung ke server ini untuk pemantauan.

Menggunakan soket selalu lebih baik karena hanya memungkinkan koneksi lokal dan lebih aman. Anda juga dapat menutup server MariaDB dari jaringan (mis. --skip-networking) dan membiarkan MaxScale menangani koneksi "eksternal" dan meneruskannya ke server MariaDB melalui file soket UNIX.

Penguras Server

Dalam MaxScale 2.4, server backend dapat dikuras, yang berarti koneksi yang ada dapat terus digunakan, tetapi tidak ada koneksi baru yang akan dibuat ke server. Dengan fitur pengurasan, kita dapat melakukan aktivitas pemeliharaan yang lancar tanpa mempengaruhi pengalaman pengguna dari sisi aplikasi. Perhatikan bahwa menguras server dapat memakan waktu lebih lama, bergantung pada kueri yang berjalan yang perlu ditutup dengan baik.

Untuk menguras server, gunakan perintah berikut:

Efek setelahnya dapat berupa salah satu dari status berikut:

• Draining - Server sedang dikuras.
• Drained - Server telah dikuras. Server sedang dikuras dan sekarang jumlah koneksi ke server turun menjadi 0.
• Pemeliharaan - Server sedang dalam pemeliharaan.

Setelah server dikuras, status server MariaDB dari sudut pandang MaxScale adalah "Pemeliharaan":

Saat server dalam mode pemeliharaan, tidak ada koneksi yang dibuat ke server tersebut dan koneksi yang ada akan ditutup.

Kesimpulan

MaxScale 2.4 membawa banyak peningkatan dan perubahan dari versi sebelumnya dan merupakan proxy database terbaik untuk menangani server MariaDB dan semua komponennya.