KAL
Menu

Kesadaran Replikasi

Binlog, format pencatatan, dan posisi read replica sebagai dasar replikasi.

Daftar isi

Replikasi memungkinkan perubahan data pada satu server diteruskan secara otomatis ke server lain, dan fondasi mekanismenya adalah binlog (binary log), yaitu catatan berurutan atas setiap perubahan yang ditulis server ke basis data. Topik ini membangun kesadaran atas bagian-bagian dasarnya: keberadaan dan tujuan binlog, format pencatatan yang menentukan bentuk catatannya, serta posisi binlog yang menandai sejauh mana sebuah replica sudah membaca. Setelah membacanya, istilah posisi dan lag pada pembicaraan tentang read replica dapat diikuti dengan pemahaman mekanisme di baliknya.

Binlog dan tujuannya#

Binlog berbeda dari log lain pada server MySQL. Log error mencatat kejadian operasional server, log query lambat mencatat pernyataan yang melewati ambang waktu, sedangkan binlog mencatat perubahan data itu sendiri. Tujuannya dua arah: menjadi aliran perubahan yang dikirim ke replica pada replikasi, dan menjadi bahan pemulihan titik waktu (point-in-time recovery) yang menyeimbangkan kelemahan dump pada topik Cadangan.

Keaktifan binlog dinyatakan oleh variabel log_bin, dan pada server latihan jalur ini binlog sudah menyala dari awal.

bash 
# memeriksa status dan pengaturan dasar binlog
mysql -t -u root <<'SQL'
SHOW VARIABLES LIKE 'log_bin';
SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';
SQL
text Keluaran 
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| log_bin       | ON    |
+---------------+-------+
+----------------------------+---------+
| Variable_name              | Value   |
+----------------------------+---------+
| binlog_expire_logs_seconds | 2592000 |
+----------------------------+---------+

Binlog ditulis sebagai rangkaian berkas bernomor, misalnya binlog.000001, binlog.000002, dan seterusnya, yang bergeser ke berkas baru saat ukurannya mencapai batas atau saat server dimulai ulang. Variabel binlog_expire_logs_seconds menetapkan umur berkas lama sebelum dibuang, pada server ini 2592000 detik atau tiga puluh hari, dan nilai tersebut menyeimbangkan kebutuhan pemulihan dengan ruang disk yang terpakai.

Format pencatatan#

Format binlog menentukan apa yang dituliskan server ke dalam catatannya. Format STATEMENT menuliskan pernyataan SQL aslinya, format ROW menuliskan perubahan baris yang terjadi, dan format MIXED membiarkan server memilih keduanya per kejadian. MySQL 8.0 menjadikan ROW sebagai format bawaan, dan pilihan itu dapat diverifikasi bersama pengaturan gambar barisnya.

bash 
# memeriksa format pencatatan dan gambar barisnya
mysql -t -u root <<'SQL'
SHOW VARIABLES LIKE 'binlog_format';
SHOW VARIABLES LIKE 'binlog_row_image';
SQL
text Keluaran 
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| binlog_format | ROW   |
+---------------+-------+
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| binlog_row_image | FULL  |
+------------------+-------+

Format ROW lebih aman untuk replikasi karena catatannya deterministik. Satu UPDATE yang memakai fungsi waktu atau nilai acak menghasilkan baris baru yang sama persis pada semua server, karena yang dikirim adalah hasil sebelum dan sesudahnya, bukan rumus yang bisa menghitung berbeda. Harga yang dibayar adalah ukuran catatan yang lebih besar, karena satu UPDATE beruntun yang menyentuh sepuluh ribu baris ditulis sebagai sepuluh ribu perubahan baris.

Variabel binlog_row_image mengatur kelengkapan gambar baris yang dicatat. Nilai FULL, yang berlaku pada server ini, menuliskan seluruh kolom pada gambar sebelum dan sesudah perubahan, sedangkan nilai MINIMAL hanya menuliskan kolom kunci dan kolom yang berubah. Nilai FULL membuat catatan lebih besar tetapi membuat replica lebih tangguh karena setiap kolom tersedia saat pemutaran ulang.

Posisi binlog dan read replica#

Sebuah server sumber (source) menulis peristiwa ke binlog secara berurutan, dan setiap peristiwa menempati titik yang jelas, yaitu pasangan nama berkas dan posisi byte di dalamnya. Replica membaca aliran itu mulai dari satu titik yang disepakati, lalu terus mengikuti, dan pasangan titik inilah yang disebut posisi replica.

Posisi berjalan pada server sumber dapat dilihat dengan SHOW MASTER STATUS, tetapi keluarannya sengaja tidak ditempelkan di sini: nama berkas dan angka posisinya berbeda pada setiap server dan berubah pada setiap penulisan, sehingga hanya bentuknya yang perlu dikenali.

sql Bentuk keluaran posisi binlog pada server sumber 
-- tidak-dijalankan
SHOW MASTER STATUS;

Keluarannya berupa satu baris berkolom File, Position, Binlog_Do_DB, dan Binlog_Ignore_DB, misalnya nama berkas binlog.000042 dengan posisi 1204. Perintah SHOW BINLOG EVENTS memuat daftar peristiwa pada berkas tertentu beserta posisi awal dan akhirnya, dan kedua perintah tersebut menjadi alat membaca peta aliran perubahan.

Sebuah replica diperintahkan untuk mengikuti sumber dengan menyebut alamat sumber beserta titik mulainya, sebagaimana bentuk perintah berikut, lalu status pengikutannya dibaca dengan SHOW REPLICA STATUS.

sql Bentuk perintah pengaitan read replica 
-- tidak-dijalankan
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST = 'server-sumber',
  SOURCE_USER = 'replikator',
  SOURCE_PASSWORD = 'kata-sandi',
  SOURCE_LOG_FILE = 'binlog.000042',
  SOURCE_LOG_POS = 1204;
START REPLICA;

Keluaran SHOW REPLICA STATUS berbentuk vertikal dengan banyak kolom, dan tiga kelompoknya paling sering dibaca: Replica_IO_Running dan Replica_SQL_Running yang harus sama-sama bernilai Yes ketika replikasi sehat, Source_Log_File beserta Read_Source_Log_Pos yang menunjukkan sejauh mana replica membaca, dan Seconds_Behind_Source yang memperkirakan keterlambatan. Selisih antara posisi terkini di sumber dan posisi yang sudah diputar di replica itulah yang disebut lag, dan pemantauan replikasi pada praktiknya berarti memantau angka-angka tersebut.

Kesalahan umum#

Kesalahan pertama adalah mematikan binlog dengan alasan hemat ruang, lalu kehilangan kemampuan pemulihan titik waktu sekaligus. Dump murni hanya menangkap satu titik waktu, sedangkan binlog menyediakan perubahan setelahnya, sehingga strategi cadangan yang sehat memakai keduanya dan ruang disknya dihitung sejak awal.

Kesalahan kedua adalah menganggap format STATEMENT lebih hemat dan langsung lebih baik. Format itu memang lebih ramping, tetapi pernyataan yang tidak deterministik, misalnya yang memakai fungsi waktu, nilai acak, atau urutan baca tabel tanpa ORDER BY yang pasti, dapat menghasilkan baris yang berbeda antara sumber dan replica. Format bawaan ROW ada karena alasan tersebut.

Kesalahan ketiga adalah membiarkan binlog tumbuh tanpa pengaturan masa kedaluwarsa. Tanpa binlog_expire_logs_seconds yang wajar, berkas binlog menumpuk hingga disk penuh dan server berhenti menulis. Pengaturan umurnya disesuaikan dengan jendela pemulihan yang benar-benar dibutuhkan, bukan dihilangkan.

Ringkasan#

  • Binlog mencatat setiap perubahan data secara berurutan dalam berkas bernomor dan menjadi dasar replikasi sekaligus pemulihan titik waktu.
  • Format ROW adalah bawaan MySQL 8.0 karena catatannya deterministik, dengan binlog_row_image FULL mencatat seluruh kolom sebelum dan sesudah perubahan.
  • Posisi replica adalah pasangan nama berkas binlog dan posisi byte pada server sumber, dan lag adalah selisih antara posisi sumber dan posisi yang sudah diputar replica.
  • Keluaran yang memuat nama berkas dan angka posisi berubah terus, sehingga hanya bentuknya yang dikenalkan dan angkanya tidak dikutip sebagai contoh tetap.

Referensi#