MySQL tidak membatasi jumlah budak yang dapat Anda sambungkan ke server master dalam topologi replikasi. Namun, karena jumlah budak meningkat, mereka akan membebani sumber daya master karena log biner perlu disajikan ke budak yang berbeda yang bekerja pada kecepatan yang berbeda. Jika churn data pada master tinggi, penyajian log biner saja dapat memenuhi antarmuka jaringan master.
Solusi klasik untuk masalah ini adalah dengan menggunakan server binlog – server proxy perantara yang berada di antara master dan slave. Server binlog diatur sebagai budak ke master, dan pada gilirannya, bertindak sebagai master ke kumpulan budak asli. Ia menerima peristiwa log biner dari master, tidak menerapkan peristiwa ini, tetapi menyajikannya ke semua budak lainnya. Dengan cara ini, beban pada master sangat berkurang, dan pada saat yang sama, server binlog melayani binlog lebih efisien ke slave karena tidak perlu melakukan pemrosesan server database lainnya.
Ripple adalah server binlog sumber terbuka yang dikembangkan oleh Pavel Ivanov. Sebuah posting blog dari Percona, berjudul MySQL Ripple:The First Impression of a MySQL Binlog Server, memberikan pengenalan yang sangat baik untuk menyebarkan dan menggunakan Ripple. Saya memiliki kesempatan untuk menjelajahi Ripple lebih detail dan ingin membagikan pengamatan saya melalui pos ini.
1. Dukungan untuk replikasi berbasis GTID
Ripple hanya mendukung mode GTID, dan bukan replikasi berbasis file dan posisi. Jika master Anda berjalan dalam mode non-GTID, Anda akan mendapatkan kesalahan ini dari Ripple:
Gagal membaca paket:Mendapat kesalahan saat membaca paket dari server:Utas pengirim replikasi tidak dapat dimulai dalam mode AUTO_POSITION:server ini memiliki GTID_MODE =OFF, bukan ON.
Anda dapat menentukan Server_id dan UUID untuk server ripple menggunakan opsi baris cmd: -ripple_server_id dan -ripple_server_uuid
Keduanya adalah parameter opsional, dan jika tidak ditentukan, Ripple akan menggunakan server_id=112211 default dan uuid akan dibuat secara otomatis.
2. Menghubungkan ke master menggunakan pengguna dan kata sandi replikasi
Saat menghubungkan ke master, Anda dapat menentukan pengguna dan sandi replikasi menggunakan opsi baris perintah:
-ripple_master_user dan -ripple_master_password
3. Titik akhir koneksi untuk server Ripple
Anda dapat menggunakan opsi baris perintah -ripple_server_ports dan -ripple_server_address untuk menentukan titik akhir koneksi untuk server Ripple. Pastikan untuk menentukan hostname atau alamat IP yang dapat diakses jaringan dari server Ripple Anda sebagai -rippple_server_address. Jika tidak, secara default, Ripple akan mengikat ke localhost dan karenanya Anda tidak akan dapat menghubungkannya dari jarak jauh.
4. Menyiapkan budak ke server Ripple
Anda dapat menggunakan perintah CHANGE MASTER TO untuk menghubungkan slave Anda untuk direplikasi dari server Ripple.
Untuk memastikan bahwa Ripple dapat mengautentikasi kata sandi yang Anda gunakan untuk menghubungkannya, Anda perlu memulai Ripple dengan menentukan opsi -ripple_server_password_hash
Misalnya, jika Anda memulai server ripple dengan perintah:
rippled -ripple_datadir=./binlog_server -ripple_master_address=
Anda dapat menggunakan perintah CHANGE MASTER TO berikut untuk menghubungkan dari slave:
GANTI MASTER KE master_host='172.31.23.201', master_port=15000, master_password='XpKWeZRNH5#satCI', master_user='rep'
Perhatikan bahwa hash kata sandi yang ditentukan untuk server Ripple sesuai dengan kata sandi teks yang digunakan dalam perintah CHANGE MASTER TO. Saat ini, Ripple tidak mengautentikasi berdasarkan nama pengguna dan menerima nama pengguna yang tidak kosong selama kata sandinya cocok.
Menjelajahi Server Binlog MySQL - RippleClick To Tweet5. Manajemen server riak
Dimungkinkan untuk memantau dan mengelola server Ripple menggunakan protokol MySQL dari klien MySQL standar mana pun. Ada sekumpulan perintah terbatas yang didukung yang dapat Anda lihat langsung di kode sumber di halaman GitHub mysql-ripple.
Beberapa perintah yang berguna adalah:
PILIH @@global.gtid_executed;– Untuk melihat SET GTID server Ripple berdasarkan log biner yang diunduh.HENTIKAN BUDAK;– Untuk memutuskan server Ripple dari master.MULAI BUDAK;– Untuk menghubungkan server Ripple ke master.
Masalah Umum &Saran untuk Peningkatan
1. Saya tidak melihat opsi untuk menyiapkan saluran replikasi SSL dari server Ripple ke master
Akibatnya, server Ripple tidak akan dapat terhubung ke master yang mengamanatkan koneksi terenkripsi. Mencoba menghubungkan akan menghasilkan kesalahan:
0322 09:01:36.555124 14942 mysql_master_session.cc:164] Gagal terhubung ke host:
2. Saya tidak dapat membuat server Ripple bekerja dengan opsi semi-sinkronisasi
Saya memulai server Ripple menggunakan opsi -ripple_semi_sync_slave_enabled=true
Saat menghubungkannya, master dapat mendeteksi server Ripple sebagai budak yang diaktifkan semi-sinkron.
mysql> tampilkan status seperti 'rpl%';
--------------------------------- ------------
| Nama_variabel | Nilai |
-------------------------------------------- -------
| Rpl_semi_sync_master_clients | 1 |
| Rpl_semi_sync_master_status | AKTIF |
| Rpl_semi_sync_slave_status | NONAKTIF |
-------------------------------------------- ----------
Namun, mencoba menjalankan transaksi dalam mode semi-sinkronisasi menunggu rpl_semi_sync_master_timeout yang 180000
mysql> buat database d12;
Kueri OK, 1 baris terpengaruh (3 menit 0,01 detik)
Saya dapat melihat bahwa semi-sinkronisasi dimatikan pada master:
mysql> tampilkan status seperti 'rpl%';
+-------------------------------- ------------+-------+
| Nama_variabel | Nilai |
+------------------------------------------------------ -+-------+
| Rpl_semi_sync_master_clients | 1 |
| Rpl_semi_sync_master_status | NONAKTIF |
| Rpl_semi_sync_slave_status | NONAKTIF |
+------------------------------------------------------ --+-------+
Cuplikan yang sesuai dari log kesalahan mysql:
2020-03-21T10:05:56.000612Z 52 [Catatan] Mulai binlog_dump ke master_thread_id(52) slave_server(112211), pos(, 4)
2020-03-21T10:05:56.000627Z 52 [ Catatan] Mulai semi-sync binlog_dump ke slave (server_id:112211), pos(, 4)
20020-03-21T10:08:55.873990Z 2 [Peringatan] Timeout menunggu balasan dari binlog (file:mysql-bin .000010, pos:350), semi-sinkronisasi hingga file , posisi 4.
2020-03-21T10:08:55.874044Z 2 [Catatan] Replikasi semi-sinkron dimatikan.
Ada masalah yang dilaporkan di sepanjang baris serupa di sini di halaman MySQL Ripple Github.
3. Masalah saat menggunakan replikasi paralel untuk budak server Ripple
Saya melihat bahwa utas SQL pada slave sering berhenti dengan kesalahan:
Last_SQL_Error:Tidak dapat menjalankan grup acara saat ini dalam mode paralel. Menemukan peristiwa Gtid, nama relai-log /mysql_data/relaylogs/relay-log.000005, posisi 27023962 yang mencegah eksekusi grup peristiwa ini dalam mode paralel. Alasan:Acara master secara logis diberi stempel waktu yang salah.
Menganalisis log relai dan posisi di atas mengungkapkan bahwa 'nomor urut' transaksi pada saat ini direset ke 1. Saya melacak penyebab rotasi binlog yang terjadi pada tuan asli. Biasanya, untuk budak langsung, ada peristiwa rotasi karena log relai juga akan berputar berdasarkan rotasi log biner master. Penilaian saya adalah bahwa kondisi seperti itu dapat dideteksi dan pengaturan ulang nomor urut dapat ditangani oleh utas paralel. Tetapi ketika nomor urut berubah tanpa rotasi log relai, kami melihat utas paralel gagal.
Pengamatan ini dilaporkan sebagai masalah:kegagalan utas paralel slave saat menyinkronkan dari server binlog #26
4. utilitas mysqlbinlog tidak bekerja pada log biner yang dihasilkan oleh server Ripple
Mencoba menjalankan utilitas mysqlbinlog pada log biner menghasilkan kesalahan:
ERROR:Error in Log_event::read_log_event():'Found invalid event in binary log', data_len:43, event_type:-106
Masalah ini diangkat di sini:Tidak dapat membuka file log biner menggunakan utilitas mysqlbinlog. #25
Ini diakui oleh penulis sebagai masalah umum. Saya merasa akan berguna untuk mendukung utilitas ini untuk tujuan debugging.
Itulah laporan untuk saat ini dari pengujian cepat saya. Saya berencana untuk memperbarui posting blog ini ketika saya menemukan lebih banyak temuan di Ripple. Secara keseluruhan, menurut saya sederhana dan mudah digunakan dan berpotensi menjadi standar untuk server binlog di lingkungan MySQL.
|
