Dunia MySQL & MariaDB

Panduan Replikasi MySQL: Setup, Pemecahan Masalah, Manajemen

Tingkat Lanjut
目次

1. Apa itu Replikasi MySQL? Gambaran Umum dan Penggunaannya

Replikasi MySQL adalah fitur yang menyinkronkan salinan basis data secara real-time ke server lain. Dengan cara ini, redundansi dan kinerja basis data dapat ditingkatkan. Berikut ini penjelasan detail tentang skenario penggunaan replikasi MySQL serta cara kerjanya.

Gambaran Umum Replikasi MySQL

Replikasi MySQL berbagi isi basis data antar beberapa server melalui konfigurasi server master dan server slave. Secara spesifik, pembaruan data yang dicatat pada binary log oleh server master dibaca dan diterapkan oleh server slave untuk menyinkronkan data. Dengan cara ini, layanan dapat terus berlanjut dengan beralih ke server slave jika server master mengalami kegagalan.

Penggunaan Replikasi MySQL

Replikasi MySQL banyak digunakan untuk keperluan berikut.
  • Menjamin Ketersediaan Tinggi: Dengan menggunakan server slave saat terjadi kegagalan, downtime dapat diminimalkan.
  • Pembagian Beban: Menyalurkan query baca‑saja ke server slave untuk mendistribusikan beban pada server master.
  • Perlindungan Data dan Cadangan: Karena replikasi menggandakan data secara real-time, dapat juga digunakan sebagai backup.

Jenis Replikasi

Replikasi MySQL memiliki jenis-jenis berikut berdasarkan cara sinkronisasi data.
  • Replikasi Asinkron: Master melanjutkan proses tanpa menunggu master mengirimkan informasi pembaruan ke slave, sehingga respons cepat. Namun, saat terjadi kegagalan, sebagian data mungkin tidak sampai ke slave.
  • Replikasi Semi‑Sinkron: Proses dilanjutkan setelah memastikan data telah tercermin di sisi slave, sehingga lebih dapat diandalkan dibanding asinkron, namun kecepatan responsnya sedikit lebih lambat.
Pada bagian berikutnya, akan dijelaskan konsep dasar replikasi MySQL seperti binary log dan GTID.

2. Konsep Dasar Replikasi MySQL

Untuk memahami replikasi MySQL, penting untuk memahami peran binary log dan GTID (Global Transaction ID). Elemen-elemen ini menjadi dasar agar data dapat direplikasi secara akurat.

Peran Master dan Slave

Dalam replikasi MySQL, server master dan server slave masing-masing memiliki peran yang berbeda. Server master mencatat perubahan data ke dalam binary log dan mendistribusikannya ke slave. Server slave menerapkan log yang diterima dari master dan memperbarui data. Dengan cara ini, slave dapat mempertahankan konten yang sama dengan data terbaru dari master.

Binary Log dan Relay Log

Pada dasar replikasi MySQL, dua jenis log berikut digunakan.
  1. binary log（Binary Log）
  • Binary log adalah catatan pembaruan data (INSERT、UPDATE、DELETE, dll.) pada server master. Hal ini memungkinkan server slave mempertahankan keadaan data yang sama dengan master.
  1. relay log（Relay Log）
  • Relay log adalah salinan binary log yang diterima oleh server slave dan disimpan di sistemnya. Thread SQL pada slave mengeksekusi relay log ini secara berurutan untuk merefleksikan perubahan data.

Apa itu GTID (Global Transaction ID)

GTID adalah mekanisme yang memberikan ID unik untuk setiap transaksi, membantu menjaga konsistensi sinkronisasi di antara banyak slave. Dengan menggunakan GTID, tidak perlu menentukan posisi binary log, sehingga hanya transaksi yang belum diambil dari master yang secara otomatis diterapkan ke slave, yang menyederhanakan manajemen secara signifikan.

Keuntungan GTID

  • Identifikasi unik: Setiap transaksi diberikan GTID unik, sehingga jelas transaksi mana yang sudah diterapkan.
  • Pemulihan mudah: Dengan GTID, meskipun master atau slave di-restart, hanya transaksi yang belum diterapkan yang akan diterapkan kembali.
  • Efisiensi manajemen operasional: Bahkan dalam lingkungan berskala besar dengan banyak server slave, manajemen menjadi mudah sambil menjaga konsistensi transaksi.
Untuk menggunakan GTID, pengaturan gtid_mode=ON dan enforce_gtid_consistency=ON wajib. Dengan mengatur ini pada master dan slave, replikasi berbasis GTID dapat diaktifkan. Pada bagian berikutnya, akan dijelaskan langkah-langkah penyiapan replikasi MySQL secara konkret.

3. Langkah-langkah Penyiapan Replikasi MySQL

Di sini, kami menjelaskan secara detail langkah-langkah untuk menyiapkan replikasi MySQL. Dengan mengikuti langkah-langkah berikut, Anda dapat melakukan konfigurasi dasar master dan slave, serta mewujudkan sinkronisasi data secara real-time.

Pengaturan Server Master

Pertama, edit file konfigurasi server master (biasanya my.cnf atau my.ini) untuk mengaktifkan binary log dan mengatur ID server.
  1. Edit File Konfigurasi
  • Tambahkan pengaturan berikut ke bagian [mysqld] dan atur ID server dengan nilai unik (contoh: 1).
   [mysqld]
   server-id=1
   log-bin=mysql-bin
  • server-id harus ditetapkan dengan nomor unik yang berbeda untuk setiap server, dan log-bin berarti mengaktifkan binary log.
  1. Membuat Pengguna Replikasi
  • Buat pengguna khusus untuk replikasi pada server master dan berikan hak yang diperlukan.
   CREATE USER 'repl'@'%' IDENTIFIED BY 'password';
   GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
   FLUSH PRIVILEGES;
  • Pengguna ini diperlukan agar server slave dapat mengakses data master.
  1. Memeriksa Status Master
  • Periksa file binary log dan posisi (lokasi log) saat ini. Informasi ini diperlukan untuk konfigurasi server slave.
   SHOW MASTER STATUS;
  • File (File, nama file log) dan Position (posisi) yang ditampilkan oleh perintah ini akan digunakan dalam konfigurasi sisi slave.

Pengaturan Server Slave

Selanjutnya, edit file konfigurasi server slave dan atur ID server serta informasi master.
  1. Edit File Konfigurasi
  • Server slave juga harus mengatur server-id secara unik (contoh: 2). ID server harus berbeda dari server master.
   [mysqld]
   server-id=2
  • Untuk mencegah penulisan data pada server slave, biasanya juga diatur read_only=ON.
  1. Mengatur Informasi Master pada Slave
  • Jalankan perintah berikut pada server slave untuk menentukan nama host master, pengguna, nama file binary log, dan posisi.
   CHANGE MASTER TO
       MASTER_HOST='master_host',
       MASTER_USER='repl',
       MASTER_PASSWORD='password',
       MASTER_LOG_FILE='mysql-bin.000001',
       MASTER_LOG_POS=123;
  • Masukkan nilai yang telah Anda periksa pada master ke MASTER_LOG_FILE dan MASTER_LOG_POS.
  1. Memulai Replikasi
  • Jalankan perintah berikut pada server slave untuk memulai replikasi.
   START SLAVE;

Memeriksa Status Replikasi

Periksa apakah replikasi telah dikonfigurasi dengan benar antara master dan slave.
  • Memeriksa Status Master
  SHOW MASTER STATUS;
  • Memeriksa Status Slave
  SHOW SLAVE STATUSG;
  • Jika Slave_IO_Running dan Slave_SQL_Running menampilkan Yes, replikasi berfungsi dengan normal.
Pada bagian berikutnya, kami akan menjelaskan metode konfigurasi lanjutan untuk replikasi MySQL. Kami akan membahas perbedaan antara replikasi asinkron dan semi-sinkron, serta langkah-langkah konfigurasi yang memanfaatkan GTID.

4. Jenis dan Penerapan Replikasi

Replikasi MySQL memiliki dua jenis, yaitu replikasi asinkron dan replikasi semi-sinkron, tergantung pada cara sinkronisasi data. Dengan memahami karakteristik masing-masing dan kriteria pemilihan yang sesuai dengan skenario penggunaan, Anda dapat meningkatkan kinerja dan keandalan sistem. Selain itu, di sini juga dijelaskan keuntungan pengaturan replikasi yang memanfaatkan GTID (Global Transaction Identifier).

Perbedaan Replikasi Asinkron dan Replikasi Semi-sinkron

1. Replikasi Asinkron

Replikasi asinkron mengembalikan respons ke klien segera setelah server master menyelesaikan transaksi. Artinya, meskipun sinkronisasi data ke server slave masih tertunda, master dapat memproses permintaan baru. Karena itu, memiliki kinerja respons yang baik dan cocok untuk sistem yang bertujuan melakukan load balancing. Namun, perlu diingat bahwa saat terjadi kegagalan, data yang belum tercermin di server slave berpotensi hilang.

2. Replikasi Semi-sinkron

Replikasi semi-sinkron mengembalikan respons ke klien setelah server master memastikan bahwa transfer data ke server slave telah selesai. Dengan cara ini, integritas data meningkat, namun waktu respons transaksi dapat menjadi lebih lama karena menunggu pencerminan di slave. Replikasi semi-sinkron cocok untuk sistem yang memerlukan integritas data yang tinggi atau lingkungan yang mengutamakan keandalan data.

Replikasi dengan Memanfaatkan GTID

GTID (Global Transaction Identifier) memberikan ID unik untuk setiap transaksi, sehingga master dan slave dapat menjaga konsistensi transaksi. Mengaktifkan GTID membuat pengelolaan replikasi menjadi lebih mudah dibandingkan dengan replikasi berbasis penunjukan posisi binary log tradisional.

Keuntungan GTID

  • Peningkatan integritas data: Dengan GTID, transaksi yang belum diterapkan di sisi slave dapat dikenali secara otomatis, sehingga integritas data lebih mudah dipertahankan.
  • Penyederhanaan manajemen replikasi: Menggunakan GTID memungkinkan pergantian atau pemulihan master dan slave dilakukan secara efisien. Karena tidak perlu lagi menentukan posisi binary log, manajemennya menjadi lebih sederhana.

Pengaturan Replikasi GTID

Untuk memanfaatkan GTID, Anda perlu menambahkan opsi berikut ke file konfigurasi master dan slave, serta mengaktifkannya. Pengaturan Server Master
[mysqld]
server-id=1
log-bin=mysql-bin
gtid_mode=ON
enforce_gtid_consistency=ON
Pengaturan Server Slave
[mysqld]
server-id=2
gtid_mode=ON
enforce_gtid_consistency=ON
read_only=ON
Di lingkungan yang mengaktifkan GTID, cukup gunakan perintah CHANGE MASTER TO pada slave untuk mengatur informasi master, dan replikasi berbasis GTID akan berjalan secara otomatis. Pada bagian berikutnya, akan dijelaskan cara pemeliharaan replikasi MySQL serta poin-poin pemantauan dalam manajemen operasional.

5. Pemeliharaan dan Pemantauan Replikasi

Untuk mengoperasikan replikasi MySQL dengan tepat, pemeliharaan dan pemantauan secara berkala sangat penting. Pada bagian ini, kami menjelaskan perintah-perintah untuk memeriksa apakah replikasi berfungsi dengan baik serta cara menangani kesalahan umum.

Cara Memeriksa Status Replikasi

Untuk memahami status replikasi, gunakan perintah berikut untuk memeriksa sinkronisasi antara master dan slave.

Memeriksa Status Master

Status replikasi pada server master dapat dilihat dengan perintah SHOW MASTER STATUS. Perintah ini menampilkan nama file binary log dan posisi saat ini, sehingga Anda dapat memeriksa pembaruan terbaru yang harus diteruskan ke slave.
SHOW MASTER STATUS;
Output dari perintah ini mencakup item-item berikut:
  • File: Nama file binary log yang sedang dihasilkan oleh master
  • Position: Posisi saat ini dalam binary log
  • Binlog_Do_DB dan Binlog_Ignore_DB: Database yang menjadi target replikasi

Memeriksa Status Slave

Status replikasi pada server slave dapat dilihat dengan perintah SHOW SLAVE STATUS. Hasil perintah ini berisi informasi untuk menilai apakah server slave beroperasi dengan normal.
SHOW SLAVE STATUSG;
Item penting yang perlu diperhatikan antara lain:
  • Slave_IO_Running dan Slave_SQL_Running: Jika keduanya Yes, berarti slave beroperasi dengan normal.
  • Seconds_Behind_Master: Menunjukkan berapa detik slave tertinggal dari master. Idealnya nilai ini adalah 0.

Pemecahan Masalah Replikasi

Masalah yang sering muncul selama operasi replikasi meliputi kesalahan koneksi dan inkonsistensi data. Berikut adalah pesan kesalahan umum beserta cara menanganinya.

1. Kesalahan Koneksi

Jika Slave_IO_Running bernilai No, berarti slave tidak dapat terhubung ke master. Coba langkah-langkah berikut.
  • Periksa nama host atau alamat IP server master: Pastikan alamat master sudah benar.
  • Periksa pengaturan firewall: Pastikan port yang diperlukan (biasanya 3306) terbuka.

2. Inkonsistensi Data

Jika Last_Error berisi detail kesalahan, kemungkinan terjadi inkonsistensi data antara master dan slave. Saat inkonsistensi terjadi, slave harus dihentikan sementara untuk diperbaiki.
STOP SLAVE;
# Lanjutkan setelah perbaikan
START SLAVE;

3. Mengatasi Keterlambatan

Penyebab keterlambatan slave dapat berupa kinerja perangkat keras slave atau masalah jaringan. Jika diperlukan, memperkuat konfigurasi slave dapat membantu memperbaikinya. Pada bagian berikutnya, kami akan membahas lebih detail tentang masalah replikasi dan solusi-solusinya.

6. Masalah Umum dan Cara Menanganinya

Dalam replikasi MySQL, berbagai masalah dapat muncul selama operasi. Di sini kami menjelaskan secara detail masalah umum dan cara menanganinya. Dengan menemukan masalah lebih awal dan menanganinya secara tepat, Anda dapat menjaga sistem tetap berjalan stabil.

1. Jika Slave_IO_Running berhenti

Gejala：Jika output perintah SHOW SLAVE STATUS menunjukkan bahwa Slave_IO_Running bernilai No, itu menandakan bahwa slave tidak dapat terhubung ke master. Penyebab dan Solusi：
  • Masalah jaringan：Jika ada masalah pada koneksi jaringan, slave tidak dapat mengakses master. Periksa pengaturan firewall dan pastikan dapat mengakses master.
  • Kesalahan pengaturan nama host atau alamat IP master：Pastikan nama host atau alamat IP yang ditentukan dengan CHANGE MASTER TO tidak salah.
  • Masalah hak pengguna：Jika pengguna replikasi yang diatur di sisi master tidak memiliki hak yang cukup, koneksi juga akan gagal. Periksa apakah hak yang tepat telah diberikan dengan GRANT REPLICATION SLAVE.

2. Inkonsistensi data pada slave

Gejala：Jika data antara slave dan master tidak cocok, data pada slave dapat menjadi tidak konsisten. Penyebab dan Solusi：
  • Perbaikan data manual：Jika terjadi inkonsistensi, hentikan slave, perbaiki transaksi yang bermasalah secara manual. Setelah perbaikan, jalankan kembali slave untuk mengembalikan replikasi ke kondisi normal.STOP SLAVE; # Perbaiki data jika diperlukan START SLAVE;
  • Sinkronisasi ulang data：Jika inkonsistensi berskala besar terjadi, ambil backup penuh data dari master dan lakukan sinkronisasi ulang ke slave untuk menyelesaikannya.

3. Keterlambatan replikasi

Gejala：Jika output SHOW SLAVE STATUS menunjukkan Seconds_Behind_Master tidak bernilai 0, itu menandakan slave tertinggal dari master. Umumnya, nilai yang lebih kecil lebih ideal. Penyebab dan Solusi：
  • Kinerja perangkat keras slave：Jika spesifikasi server slave rendah, proses tidak dapat mengimbangi sehingga terjadi keterlambatan. Upgrade perangkat keras dapat efektif.
  • Optimasi kueri：Jika kueri yang dikirim dari master memerlukan waktu lama untuk dieksekusi di slave, keterlambatan akan terjadi. Menambahkan indeks atau mengoptimalkan kueri dapat memperpendek waktu proses.

4. Kesalahan hak pengguna replikasi

Gejala：Jika Last_Error menampilkan pesan kesalahan terkait hak, kemungkinan slave tidak memiliki hak yang diperlukan untuk terhubung ke master. Penyebab dan Solusi：
  • Pemberian hak melalui pengaturan ulang：Pastikan pengguna dengan hak yang tepat telah dibuat di master, dan jika perlu lakukan pengaturan ulang.GRANT REPLICATION SLAVE ON *.* TO 'repl'@'IP_slave'; FLUSH PRIVILEGES;

5. Pembesaran binary log

Gejala：Binary log pada master dapat menjadi sangat besar, sehingga memakan ruang disk server. Penyebab dan Solusi：
  • Rotasi binary log：Dengan secara berkala menghapus atau mengarsipkan binary log, pertumbuhan dapat dicegah. Mengatur expire_logs_days memungkinkan log yang lebih lama dari periode tertentu dihapus otomatis.SET GLOBAL expire_logs_days = 7; # Hapus log lebih dari 7 hari
Dengan memahami masalah umum dan solusi pada replikasi MySQL, Anda dapat mengelola operasi dengan lancar. Pada bagian berikutnya, kami akan meninjau poin-poin penting dalam operasi replikasi sebagai rangkuman artikel.

7. Ringkasan

Replikasi MySQL adalah fitur penting untuk meningkatkan konsistensi data dan keandalan sistem. Artikel ini menjelaskan secara detail mulai dari konsep dasar replikasi MySQL, prosedur penyiapan, hingga pemantauan dan pemecahan masalah dalam manajemen operasional. Akhirnya, kami merangkum poin-poin penting dalam manajemen operasional replikasi di bawah ini.

Tinjauan Poin-Poin Penting

  1. Jenis dan Pemilihan Replikasi
  • Replikasi asinkron memiliki kecepatan respons yang baik dan cocok untuk beban distribusi, tetapi jika mengutamakan keandalan, replikasi semi-sinkron lebih tepat. Pilih metode yang sesuai dengan kebutuhan sistem.
  1. Pemanfaatan GTID
  • Dengan memanfaatkan GTID, tidak perlu menentukan posisi binary log, sehingga manajemen transaksi menjadi lebih lancar. Ini sangat berguna dalam lingkungan dengan banyak slave atau sistem yang memerlukan pemulihan kegagalan.
  1. Pemeriksaan Status Secara Berkala
  • SHOW MASTER STATUS dan SHOW SLAVE STATUS untuk memantau secara berkala status master dan slave sangat penting. Jika terdeteksi anomali, penanganan cepat dapat meminimalkan risiko inkonsistensi data dan keterlambatan.
  1. Mempelajari Pemecahan Masalah Umum
  • Kesalahan koneksi slave, inkonsistensi data, keterlambatan, dan masalah lain sering terjadi pada replikasi MySQL. Memahami cara penyelesaian dasar untuk masing-masing masalah akan memudahkan penanganan selama operasi.
  1. Manajemen Binary Log
  • Jika binary log menjadi terlalu besar, kapasitas disk server akan tertekan, sehingga disarankan menggunakan pengaturan expire_logs_days untuk menghapus secara otomatis dan melakukan pemeliharaan secara berkala.
Replikasi MySQL bukanlah sesuatu yang selesai setelah satu kali pengaturan; pemantauan harian dan pemeliharaan yang tepat sangat penting. Dengan memeriksa status secara berkala dan meninjau pengaturan bila diperlukan, Anda dapat membangun dan mempertahankan sistem basis data yang sangat dapat diandalkan. Semoga artikel ini membantu pemahaman dan implementasi replikasi MySQL. Kami berharap operasi replikasi Anda di masa depan berjalan lancar.