ProxySQL adalah salah satu proxy terbaik untuk MySQL. Ini memperkenalkan banyak pilihan untuk administrator database. Itu memungkinkan untuk membentuk lalu lintas basis data dengan menunda, menyimpan, atau menulis ulang kueri dengan cepat. Ini juga dapat digunakan untuk membuat lingkungan di mana failover tidak akan memengaruhi aplikasi dan akan transparan bagi mereka. Kami telah membahas fitur ProxySQL yang paling penting di posting blog sebelumnya:
- Cara menggunakan ClusterControl dan ProxySQL untuk menyimpan kueri
- Cara membangun firewall SQL dengan ClusterControl dan ProxySQL
- Cara menerapkan cluster ProxySQL
- Cara mudah menerapkan lingkungan replikasi MySQL dengan ProxySQL untuk ketersediaan tinggi
Kami bahkan memiliki tutorial yang mencakup ProxySQL yang menunjukkan bagaimana ProxySQL dapat digunakan dalam penyiapan MySQL dan MariaDB.
Baru-baru ini ProxySQL 2.0.3 telah dirilis, menjadi rilis patch untuk seri 2.0. Bug sedang diperbaiki dan garis 2.0 tampaknya mulai mendapatkan traksi yang layak. Dalam posting blog ini kami ingin membahas perubahan besar yang diperkenalkan di ProxySQL 2.0.
Pembacaan Kausal Menggunakan GTID
Setiap orang yang harus berurusan dengan lag replikasi dan berjuang dengan skenario read-after-write yang dipengaruhi oleh lag replikasi pasti akan sangat senang dengan fitur ini. Sejauh ini, di lingkungan replikasi MySQL, satu-satunya cara untuk memastikan pembacaan kausal adalah membaca dari master (dan tidak masalah jika Anda menggunakan replikasi asinkron atau semisinkron). Pilihan lain adalah menggunakan Galera, yang memiliki opsi untuk menegakkan pembacaan kausal karena, seperti, selalu (dulunya wsrep-causal-reads dan sekarang wsrep-sync-wait). Baru-baru ini (di 8.0.14) replikasi Grup MySQL mendapat fitur serupa. Replikasi reguler, dengan sendirinya, tidak dapat mengatasi masalah ini. Untungnya, ProxySQL ada di sini dan ini memberi kita opsi untuk menentukan berdasarkan aturan per kueri dengan apa yang dibaca grup host yang cocok dengan aturan kueri yang harus konsisten. Implementasinya dilengkapi dengan pembaca binlog ProxySQL dan dapat bekerja dengan format binlog ROW untuk MySQL 5.7 dan yang lebih baru. Hanya Oracle MySQL yang didukung karena kurangnya fungsionalitas yang diperlukan di MariaDB. Fitur ini dan detail teknisnya telah dijelaskan di blog resmi ProxySQL.
SSL untuk Koneksi Frontend
ProxySQL selalu memiliki dukungan untuk koneksi SSL backend tetapi tidak memiliki enkripsi SSL untuk koneksi yang berasal dari klien. Ini bukan masalah besar mengingat pola penerapan yang disarankan adalah untuk menempatkan ProxySQL pada node aplikasi dan menggunakan soket Unix yang aman untuk terhubung dari aplikasi ke proxy. Ini masih merupakan rekomendasi, terutama jika Anda menggunakan ProxySQL untuk kueri caching (soket Unix lebih cepat daripada koneksi TCP, bahkan yang lokal dan dengan cache ada baiknya untuk menghindari pengenalan latensi yang tidak perlu). Apa yang baik adalah bahwa dengan ProxySQL 2.0 sekarang ada pilihan karena memperkenalkan dukungan SSL untuk koneksi masuk. Anda dapat dengan mudah mengaktifkannya dengan mengatur mysql-have_ssl ke 'true'. Mengaktifkan SSL tidak disertai dengan dampak kinerja yang tidak dapat diterima. Sebaliknya, sesuai hasil dari blog ProxySQL resmi, penurunan kinerja sangat rendah.
Dukungan Asli untuk Galera Cluster
Galera Cluster telah didukung oleh ProxySQL hampir sejak awal tetapi sejauh ini dilakukan melalui skrip eksternal yang (biasanya) telah dipanggil dari penjadwal internal ProxySQL. Terserah skrip untuk memastikan bahwa konfigurasi ProxySQL benar, penulis (atau penulis) telah terdeteksi dan dikonfigurasi dengan benar di grup host penulis. Skrip dapat mendeteksi status berbeda yang mungkin dimiliki simpul Galera (Utama, non-Utama, Disinkronkan, Donor/Desinkronisasi, Bergabung, Bergabung) dan menandai simpul yang sesuai sebagai tersedia atau tidak. Masalah utamanya adalah bahwa skrip asli tidak pernah dimaksudkan sebagai apa pun selain bukti konsep yang ditulis dalam Bash. Namun karena didistribusikan bersama dengan ProxySQL, itu mulai diperbaiki, dimodifikasi oleh kontributor eksternal. Lainnya (seperti Percona) melihat ke dalam membuat skrip mereka sendiri, dibundel dengan perangkat lunak mereka. Beberapa perbaikan telah diperkenalkan dalam skrip dari repositori ProxySQL, beberapa telah diperkenalkan ke skrip versi Percona. Hal ini menyebabkan kebingungan dan meskipun semua skrip yang umum digunakan menangani 95% kasus penggunaan, tidak ada skrip populer yang benar-benar mencakup semua situasi dan variabel yang berbeda yang mungkin digunakan oleh klaster Galera. Untungnya, ProxySQL 2.0 hadir dengan dukungan asli untuk Galera Cluster. Hal ini membuat ProxySQL mendukung replikasi MySQL secara internal, MySQL Group Replication dan sekarang Galera Cluster. Cara membuatnya sangat mirip. Kami ingin membahas konfigurasi fitur ini karena mungkin tidak jelas pada pandangan pertama.
Seperti replikasi MySQL dan Replikasi Grup MySQL, sebuah tabel telah dibuat di ProxySQL:
mysql> show create table mysql_galera_hostgroups\G
*************************** 1. row ***************************
table: mysql_galera_hostgroups
Create Table: CREATE TABLE mysql_galera_hostgroups (
writer_hostgroup INT CHECK (writer_hostgroup>=0) NOT NULL PRIMARY KEY,
backup_writer_hostgroup INT CHECK (backup_writer_hostgroup>=0 AND backup_writer_hostgroup<>writer_hostgroup) NOT NULL,
reader_hostgroup INT NOT NULL CHECK (reader_hostgroup<>writer_hostgroup AND backup_writer_hostgroup<>reader_hostgroup AND reader_hostgroup>0),
offline_hostgroup INT NOT NULL CHECK (offline_hostgroup<>writer_hostgroup AND offline_hostgroup<>reader_hostgroup AND backup_writer_hostgroup<>offline_hostgroup AND offline_hostgroup>=0),
active INT CHECK (active IN (0,1)) NOT NULL DEFAULT 1,
max_writers INT NOT NULL CHECK (max_writers >= 0) DEFAULT 1,
writer_is_also_reader INT CHECK (writer_is_also_reader IN (0,1,2)) NOT NULL DEFAULT 0,
max_transactions_behind INT CHECK (max_transactions_behind>=0) NOT NULL DEFAULT 0,
comment VARCHAR,
UNIQUE (reader_hostgroup),
UNIQUE (offline_hostgroup),
UNIQUE (backup_writer_hostgroup))
1 row in set (0.00 sec)Ada banyak pengaturan untuk dikonfigurasi dan kami akan membahasnya satu per satu. Pertama-tama, ada empat grup host:
- Writer_hostgroup - ini akan berisi semua penulis (dengan read_only=0) hingga pengaturan 'max_writers'. Secara default hanya ada satu penulis
- Backup_writer_hostgroup - berisi sisa penulis (read_only=0) yang tersisa setelah 'max_writers' ditambahkan ke writer_hostgroup
- Reader_hostgroup - berisi pembaca (read_only=1), mungkin juga berisi penulis cadangan, sesuai pengaturan 'writer_is_also_reader'
- Offline_hostgroup - berisi node yang dianggap tidak dapat digunakan (baik offline atau dalam keadaan yang membuatnya tidak mungkin menangani lalu lintas)
Kemudian kita memiliki pengaturan yang tersisa:
- Aktif - apakah entri di mysql_galera_hostgroups aktif atau tidak
- Max_writers - maksimal jumlah node yang dapat dimasukkan ke dalam writer_hostgroup
- Writer_is_also_reader - jika disetel ke 0, penulis (read_only=0) tidak akan dimasukkan ke reader_hostgroup. Jika disetel ke 1, penulis (read_only=0) akan dimasukkan ke dalam reader_hostgroup. Jika diatur ke 2, node dari backup_writer_hostgroup akan dimasukkan ke reader_hostgroup. Yang ini agak rumit oleh karena itu kami akan menyajikan contohnya nanti di posting blog ini
- Max_transactions_behind - berdasarkan wsrep_local_recv_queue, antrean maksimal yang dapat diterima. Jika antrian pada node melebihi max_transactions_behind node yang diberikan akan ditandai sebagai DIHENTIKAN dan tidak akan tersedia untuk lalu lintas
Kejutan utama mungkin adalah penanganan pembaca, yang berbeda dari cara kerja skrip yang disertakan dalam ProxySQL. Pertama-tama, apa yang harus Anda ingat, adalah fakta, bahwa ProxySQL menggunakan read_only=1 untuk memutuskan apakah node adalah pembaca atau bukan. Ini umum dalam pengaturan replikasi, tidak terlalu umum di Galera. Oleh karena itu, kemungkinan besar, Anda ingin menggunakan pengaturan 'writer_is_also_reader' untuk mengonfigurasi bagaimana pembaca harus ditambahkan ke reader_hostgroup. Mari kita pertimbangkan tiga node Galera, semuanya memiliki read_only=0. Kami juga memiliki max_writers=1 karena kami ingin mengarahkan semua penulisan ke satu node. Kami mengkonfigurasi mysql_galera_hostgroups sebagai berikut:
SELECT * FROM mysql_galera_hostgroups\G
*************************** 1. row ***************************
writer_hostgroup: 10
backup_writer_hostgroup: 30
reader_hostgroup: 20
offline_hostgroup: 40
active: 1
max_writers: 1
writer_is_also_reader: 0
max_transactions_behind: 0
comment: NULL
1 row in set (0.00 sec)Mari kita lihat semua opsi:
writer_is_also_reader=0
mysql> SELECT hostgroup_id, hostname FROM runtime_mysql_servers;
+--------------+------------+
| hostgroup_id | hostname |
+--------------+------------+
| 10 | 10.0.0.103 |
| 30 | 10.0.0.101 |
| 30 | 10.0.0.102 |
+--------------+------------+
3 rows in set (0.00 sec)Hasil ini berbeda dari yang Anda lihat di skrip - di sana Anda akan memiliki sisa node yang ditandai sebagai pembaca. Di sini, karena kami tidak ingin penulis menjadi pembaca dan karena tidak ada simpul dengan read_only=1, tidak ada pembaca yang akan dikonfigurasi. Satu penulis (sesuai max_writers), node yang tersisa di backup_writer_hostgroup.
writer_is_also_reader=1
mysql> SELECT hostgroup_id, hostname FROM runtime_mysql_servers;
+--------------+------------+
| hostgroup_id | hostname |
+--------------+------------+
| 10 | 10.0.0.103 |
| 20 | 10.0.0.101 |
| 20 | 10.0.0.102 |
| 20 | 10.0.0.103 |
| 30 | 10.0.0.101 |
| 30 | 10.0.0.102 |
+--------------+------------+
6 rows in set (0.00 sec)Disini kami ingin penulis kami bertindak sebagai pembaca sehingga mereka semua (aktif dan cadangan) akan dimasukkan ke dalam reader_hostgroup.
writer_is_also_reader=2
mysql> SELECT hostgroup_id, hostname FROM runtime_mysql_servers;
+--------------+------------+
| hostgroup_id | hostname |
+--------------+------------+
| 10 | 10.0.0.103 |
| 20 | 10.0.0.101 |
| 20 | 10.0.0.102 |
| 30 | 10.0.0.101 |
| 30 | 10.0.0.102 |
+--------------+------------+
5 rows in set (0.00 sec)Ini adalah pengaturan bagi mereka yang tidak ingin penulis aktif mereka menangani pembacaan. Dalam hal ini hanya node dari backup_writer_hostgroup yang akan digunakan untuk pembacaan. Harap diingat juga bahwa jumlah pembaca akan berubah jika Anda menyetel max_writers ke nilai lain. Jika kita menyetelnya ke 3, tidak akan ada penulis cadangan (semua node akan berakhir di grup host penulis) sehingga, sekali lagi, tidak akan ada node di grup host pembaca.
Tentu saja, Anda ingin mengonfigurasi aturan kueri sesuai dengan konfigurasi grup host. Kami tidak akan melalui proses ini di sini, Anda dapat memeriksa bagaimana hal itu dapat dilakukan di blog ProxySQL. Jika Anda ingin menguji cara kerjanya di lingkungan Docker, kami memiliki blog yang membahas cara menjalankan Galera cluster dan ProxySQL 2.0 di Docker.
Perubahan Lainnya
Apa yang kami jelaskan di atas adalah peningkatan paling menonjol di ProxySQL 2.0. Ada banyak lainnya, sesuai dengan changelog. Perlu disebutkan adalah peningkatan seputar cache kueri (misalnya, penambahan PROXYSQL FLUSH QUERY CACHE) dan perubahan yang memungkinkan ProxySQL mengandalkan super_read_only untuk menentukan master dan slave dalam penyiapan replikasi.
Kami berharap tinjauan singkat tentang perubahan di ProxySQL 2.0 ini akan membantu Anda menentukan versi ProxySQL mana yang harus Anda gunakan. Harap diingat bahwa 1.4 cabang, meskipun tidak mendapatkan fitur baru, tetap dipertahankan.
