Source dan Replica

Chapter sebelumnya memetakan ide replication; sekarang kita turun ke meja kerja dan menyusun kedua sisinya. Source dan replica adalah dua server MySQL yang berjalan terpisah — masing-masing punya datadir, port, dan konfigurasi sendiri — dan dihubungkan oleh satu akun khusus. Karena server uji course ini hanya satu instance, kita akan menjalankan nyata semua yang bisa diuji di satu server (akun replikasi, perintah START/STOP REPLICA, SHOW REPLICA STATUS) dan menandai blok yang benar-benar membutuhkan dua server sebagai ilustrasi. Hasil akhirnya: kita tahu persis urutan perintah yang dipakai operator sungguhan saat membangun replikasi pertama.

Dua Peran, Dua Pekerjaan #

Pembagian kerja keduanya simetris tapi tidak sama. Source tetap menjadi satu-satunya penerima tulisan: setiap transaksi yang di-commit di source juga dituliskan ke binary log-nya — file berisi urutan event perubahan. Replica tidak pernah ditulis oleh aplikasi secara langsung; replica membuka koneksi ke source memakai akun replikasi, menarik event dari binary log, menyimpannya di relay log, lalu menjalankan ulang event demi event dengan SQL thread miliknya.

Membuat Akun Khusus Replikasi #

Replica masuk ke source sebagai klien biasa, jadi ia butuh akun. Praktik yang benar: buat akun khusus dengan privilege minimal — hanya REPLICATION SLAVE, privilege yang hanya memberi hak menarik stream binary log, tanpa hak membaca satu tabel pun. Karena akun ini adalah objek global (bukan isi database latihan), kita bersihkan dulu sisa percobaan sebelumnya, lalu buat akunnya:

DROP USER IF EXISTS 'repl'@'%';
CREATE USER 'repl'@'%' IDENTIFIED BY 'SandiRepl2026!';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
SHOW GRANTS FOR 'repl'@'%';

Output yang Dihasilkan:

Query OK, 0 rows affected, 1 warning (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

+----------------------------------------------+
| Grants for repl@%                            |
+----------------------------------------------+
| GRANT REPLICATION SLAVE ON *.* TO `repl`@`%` |
+----------------------------------------------+
1 row in set (0.00 sec)

Mari kita bedah tiga baris intinya. Baris DROP USER IF EXISTS menjadikan blok idempoten — dijalankan berulang pun tetap aman. CREATE USER 'repl'@'%' mendaftarkan akun dengan host % (bisa konek dari mesin mana pun — di produksi, ganti dengan IP tetap replica demi permukaan serangan lebih kecil). Baris GRANT REPLICATION SLAVE ON *.* memberi privilege replikasi pada seluruh database: memang harus lintas database, karena IO thread membaca stream binlog mentah, bukan tabel tertentu. Output SHOW GRANTS memperlihatkan hasilnya — akun repl hanya memegang satu privilege, tidak lebih. Kita konfirmasi akunnya terdaftar di tabel sistem:

SELECT user, host FROM mysql.user WHERE user = 'repl' ORDER BY host;

Output yang Dihasilkan:

+------+------+
| user | host |
+------+------+
| repl | %    |
+------+------+
1 row in set (0.00 sec)

Konfigurasi Sisi Source #

Konfigurasi source hidup di file my.cnf (Linux) atau my.ini (Windows), di bagian [mysqld], lalu diikuti restart server. Blok berikut adalah konfigurasi minimal yang lazim dipakai:

[mysqld]
server_id  = 1
log_bin    = mysql-bin
binlog_format = ROW

Tiga barisnya bekerja begini: server_id = 1 memberi identitas unik kepada source; log_bin = mysql-bin mengaktifkan binary log dengan prefix nama file mysql-bin (file aktual bernomor urut: mysql-bin.000001, mysql-bin.000002, …); binlog_format = ROW memilih format event berbasis baris — format bawaan MySQL 8.4 yang mencatat hasil akhir setiap perubahan baris dan kita bahas implikasinya di chapter Batasan Replication.

Apakah binary log server uji kita menyala? Kita bisa memeriksanya tanpa membuka file konfigurasi:

SELECT @@log_bin AS log_bin;

Output yang Dihasilkan:

+---------+
| log_bin |
+---------+
|       0 |
+---------+
1 row in set (0.00 sec)

Nilai 0 menegaskan binary log tidak aktif — server uji memang dijalankan dengan --skip-log-bin agar hemat ruang disk. Perintah SHOW BINARY LOGS, yang di source sungguhan menampilkan daftar file binary log beserta ukurannya, dengan jujur menolak dijalankan di server tanpa binary log:

-- @error
SHOW BINARY LOGS;

Output yang Dihasilkan:

Query OK, 0 rows affected (0.00 sec)

ERROR 1381 (HY000): You are not using binary logging
Bye

ERROR 1381 (“You are not using binary logging”) adalah bukti nyata bahwa replikasi belum bisa dimulai dari server ini — langkah pertama operator sungguhan adalah mengaktifkan log_bin lalu me-restart server.

Konfigurasi Sisi Replica #

Replica tidak wajib mengaktifkan binary log-nya sendiri; yang wajib ada adalah server_id yang berbeda dan relay log sebagai penampung event sebelum dijalankan ulang. Konfigurasi minimalnya:

[mysqld]
server_id  = 2
relay_log  = relay-bin
read_only  = ON

Baris relay_log = relay-bin menamai file relay log (prefix relay-bin, bernomor urut seperti binary log). Baris read_only = ON menjaga replica agar hanya bisa dibaca oleh koneksi biasa — kita buktikan perilakunya di chapter Failover Concepts, termasuk fakta bahwa read_only saja tidak cukup ketat tanpa super_read_only.

Menghubungkan Kedua Sisi dengan CHANGE REPLICATION SOURCE TO #

Inilah perintah yang “memperkenalkan” replica kepada source. Karena perintah ini benar-benar membutuhkan server source yang hidup, kita tampilkan sebagai ilustrasi — perintah ini tidak bisa diuji di satu server tanpa source:

-- @notest
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST = '192.0.2.10',
  SOURCE_PORT = 3306,
  SOURCE_USER = 'repl',
  SOURCE_PASSWORD = 'SandiRepl2026!',
  SOURCE_LOG_FILE = 'mysql-bin.000003',
  SOURCE_LOG_POS = 617;

Enam parameternya masing-masing punya tugas:

Pasangan SOURCE_LOG_FILE/SOURCE_LOG_POS adalah “bookmark” replica. Nilainya diambil dari source dengan perintah SHOW BINARY LOG STATUS (perintah pengganti SHOW MASTER STATUS yang dihapus di MySQL 8.4) pada saat salinan awal data selesai dibuat. Ada moda kedua: menambahkan SOURCE_AUTO_POSITION = 1 memakai GTID (Global Transaction Identifier) sehingga replica tidak lagi dibookmark per file dan posisi, melainkan melacak daftar transaksi ber-GTID — jauh lebih mudah untuk failover, dan kita bahas lebih jauh di chapter failover.

START REPLICA Tanpa Konfigurasi: Error yang Jujur #

Setelah CHANGE REPLICATION SOURCE TO, operator menjalankan START REPLICA untuk menghidupkan IO thread dan SQL thread. Di server uji kita, perintah itu berjalan tanpa konfigurasi sumber — dan MySQL menyatakannya terus terang:

-- @error
START REPLICA;

Output yang Dihasilkan:

Query OK, 0 rows affected (0.00 sec)

ERROR 1200 (HY000): The server is not configured as replica; fix in config file or with CHANGE REPLICATION SOURCE TO
Bye

ERROR 1200 dengan pesan “The server is not configured as replica; fix in config file or with CHANGE REPLICATION SOURCE TO” — error yang persis inilah yang akan Anda temui bila menjalankan START REPLICA sebelum CHANGE REPLICATION SOURCE TO di server sungguhan. Perintah kebalikannya justru diam saja:

STOP REPLICA;
SHOW WARNINGS;

Output yang Dihasilkan:

Query OK, 0 rows affected, 1 warning (0.00 sec)

+-------+------+-----------------------------------------------------------+
| Level | Code | Message                                                   |
+-------+------+-----------------------------------------------------------+
| Note  | 3084 | Replication thread(s) for channel '' are already stopped. |
+-------+------+-----------------------------------------------------------+
1 row in set (0.00 sec)

STOP REPLICA pada server yang thread-nya memang belum pernah jalan menghasilkan Query OK dengan satu note 3084: replication thread untuk channel '' sudah berhenti. Notasi channel kosong berarti channel replikasi bawaan (channel bernama hanya muncul pada multi-source replication). Perintah pembersih juga aman dipakai:

RESET REPLICA;

Output yang Dihasilkan:

Query OK, 0 rows affected (0.00 sec)

RESET REPLICA membuang seluruh relay log, menghapus posisi bookmark, dan mengembalikan replica ke kondisi “belum dikenalkan ke source mana pun” — berguna saat kita ingin mengulang konfigurasi dari awal, dan tidak berbahaya pada server yang memang belum terkonfigurasi.

Membaca SHOW REPLICA STATUS #

Perintah pemantauan utama replica adalah SHOW REPLICA STATUS. Di server uji kita hasilnya jujur:

SHOW REPLICA STATUS\G

Output yang Dihasilkan:

Empty set (0.00 sec)

Hasil kosong (Empty set) berarti server ini belum mengenal source mana pun — belum ada baris status yang bisa dilaporkan. Pada replica sungguhan yang sudah terkonfigurasi, perintah yang sama mengeluarkan lebih dari 60 kolom dalam format vertikal (itulah guna \G di akhir — mengganti tampilan tabel selebar layar menjadi satu kolom nama-nilai). Kolom-kolom yang paling sering diperiksa operator:

Membersihkan Akun Latihan #

Akun repl hanya latihan, jadi kita jatuhkan kembali:

DROP USER 'repl'@'%';

Output yang Dihasilkan:

Query OK, 0 rows affected (0.00 sec)

Referensi #

• How to Set Up Replication — MySQL 8.4 Reference Manual
• CHANGE REPLICATION SOURCE TO Statement — MySQL 8.4 Reference Manual
• START REPLICA Statement — MySQL 8.4 Reference Manual
• SHOW REPLICA STATUS Statement — MySQL 8.4 Reference Manual

Dua sisi topologi kini terpasang di kepala kita: akun minimal di source, server_id berbeda di kedua sisi, bookmark posisi binary log, lalu START REPLICA untuk menghidupkan aliran. Namun satu pertanyaan belum terjawab: setelah START REPLICA, seberapa cepat replica menerima tulisan baru? Jawabannya — dan konsekuensinya saat server jatuh — menjadi inti chapter berikutnya tentang asynchronous replication.