Practical MySQL & MariaDB

Replikasi MySQL Dijelaskan: Panduan Penyiapan, GTID, Pemantauan, dan Pemecahan Masalah

Lanjutan / Lainnya
目次

1. Apa Itu Replikasi MySQL? Gambaran Umum dan Kasus Penggunaan

Replikasi MySQL adalah fitur yang menyinkronkan salinan basis data ke server lain secara waktu nyata. Hal ini meningkatkan redundansi dan kinerja basis data. Di bawah ini, kami menjelaskan secara detail kapan replikasi MySQL digunakan dan bagaimana cara kerjanya.

Gambaran Umum Replikasi MySQL

Replikasi MySQL membagikan isi basis data di beberapa server menggunakan server master dan satu atau lebih server slave. Secara khusus, pembaruan data yang dicatat dalam binary log server master dibaca dan diterapkan oleh server slave untuk menjaga data tetap sinkron. Ini memungkinkan kontinuitas layanan dengan beralih ke server slave jika server master mengalami kegagalan.

Kasus Penggunaan Replikasi MySQL

Replikasi MySQL banyak digunakan dalam skenario berikut:

  • Ketersediaan Tinggi : Jika terjadi kegagalan, beralih ke server slave meminimalkan waktu henti.
  • Load Balancing : Kueri hanya-baca dapat didistribusikan ke server slave, mengurangi beban pada server master.
  • Perlindungan Data dan Cadangan : Karena replikasi menggandakan data secara waktu nyata, ia juga dapat berfungsi sebagai mekanisme cadangan.

Jenis-Jenis Replikasi

Replikasi MySQL mencakup jenis-jenis berikut berdasarkan metode sinkronisasi:

  • Replikasi Asinkron : Master melanjutkan tanpa menunggu konfirmasi dari slave. Ini memungkinkan waktu respons yang lebih cepat tetapi dapat mengakibatkan sebagian data tidak sampai ke slave saat terjadi kegagalan.
  • Replikasi Semi-Sinkron : Master menunggu konfirmasi bahwa data telah diterima oleh slave sebelum melanjutkan. Ini memberikan keandalan yang lebih tinggi dibandingkan replikasi asinkron, meskipun dengan waktu respons yang sedikit lebih lambat.

Bagian berikutnya menjelaskan konsep dasar replikasi MySQL, termasuk binary log dan GTID.

2. Konsep Dasar Replikasi MySQL

Untuk memahami replikasi MySQL, penting untuk memahami peran binary log dan GTID (Global Transaction ID), yang memainkan peran penting dalam proses replikasi. Elemen‑elemen ini menjadi fondasi bagi replikasi data yang akurat.

Peran Master dan Slave

Dalam replikasi MySQL, server master dan server slave memiliki peran yang berbeda. Master mencatat pembaruan data dalam binary log dan mengirimkannya ke slave. Slave menerapkan log yang diterima untuk memperbarui datanya. Akibatnya, slave mempertahankan data yang sama dengan master.

Binary Log dan Relay Log

Replikasi MySQL bergantung pada dua log berikut:

  1. Binary Log
  • Binary log mencatat pembaruan data (seperti INSERT, UPDATE, dan DELETE) pada server master. Hal ini memungkinkan server slave mempertahankan keadaan data yang sama dengan master.
  1. Relay Log
  • Relay log menyimpan peristiwa binary log yang diterima dari master pada server slave. Thread SQL pada slave mengeksekusi relay log secara berurutan untuk menerapkan perubahan data.

Apa Itu GTID (Global Transaction ID)?

GTID adalah mekanisme yang memberikan ID unik untuk setiap transaksi, membantu menjaga konsistensi di antara banyak slave. Dengan menggunakan GTID, penentuan posisi binary log tidak lagi diperlukan. Hanya transaksi yang belum diambil dari master yang secara otomatis diterapkan ke slave, sehingga mempermudah manajemen secara signifikan.

Keuntungan GTID

  • Identifikasi Unik : Setiap transaksi diberikan GTID unik, sehingga jelas transaksi mana yang telah diterapkan.
  • Pemulihan Lebih Mudah : Saat menggunakan GTID, hanya transaksi yang belum diterapkan yang diproses ulang setelah restart master atau slave.
  • Manajemen Operasional Efisien : Bahkan dalam lingkungan berskala besar dengan banyak slave, konsistensi transaksi dapat dipertahankan dengan manajemen yang disederhanakan.

Untuk menggunakan GTID, diperlukan pengaturan gtid_mode=ON dan enforce_gtid_consistency=ON. Mengonfigurasi pengaturan ini pada master dan slave memungkinkan replikasi berbasis GTID.

Bagian berikutnya menjelaskan langkah‑langkah spesifik untuk menyiapkan replikasi MySQL.

3. Prosedur Penyiapan Replikasi MySQL

Bagian ini menjelaskan langkah‑langkah yang diperlukan untuk menyiapkan replikasi MySQL. Dengan mengikuti langkah‑langkah ini, Anda dapat mengonfigurasi struktur master‑slave dasar dan mengaktifkan sinkronisasi data secara real‑time.

Mengonfigurasi Server Master

Pertama, edit file konfigurasi server master (biasanya my.cnf atau my.ini) untuk mengaktifkan binary log dan menetapkan ID server.

  1. Edit File Konfigurasi
  • Tambahkan pengaturan berikut di bawah bagian [mysqld] dan tetapkan ID server yang unik (misalnya, 1).
    [mysqld]
server-id=1
log-bin=mysql-bin
  • server-id harus berupa angka unik untuk setiap server, dan log-bin mengaktifkan binary log.
  1. Buat Pengguna Replikasi
  • Buat pengguna replikasi khusus pada server master dan berikan hak istimewa 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 dari master.
  1. Periksa Status Master
  • Periksa file binary log dan posisi (lokasi log) saat ini. Informasi ini diperlukan saat mengonfigurasi server slave.
    SHOW MASTER STATUS;
  • File (nama file log) dan Position yang ditampilkan oleh perintah ini akan digunakan dalam konfigurasi slave.

Mengonfigurasi Server Slave

Selanjutnya, edit file konfigurasi server slave dan atur ID server serta informasi master.

  1. Edit File Konfigurasi
  • Tetapkan server-id yang unik pada server slave juga (misalnya, 2). Nilai ini harus berbeda dari ID server master.
    [mysqld]
server-id=2

  • Juga umum untuk mengatur read_only=ON agar mencegah penulisan data pada server slave. 1. Konfigurasikan Informasi Master pada Slave

  • Jalankan perintah berikut pada server slave, dengan menentukan hostname 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 dikonfirmasi sebelumnya pada master untuk MASTER_LOG_FILE dan MASTER_LOG_POS . 1. Mulai Replikasi

  • Jalankan perintah berikut pada server slave untuk memulai replikasi.

    START SLAVE;

Memverifikasi Status Replikasi

Verifikasi bahwa replikasi antara master dan slave telah dikonfigurasi dengan benar.

  • Periksa Status Master
    SHOW MASTER STATUS;
  • Periksa Status Slave
    SHOW SLAVE STATUS\G;
  • Jika Slave_IO_Running dan Slave_SQL_Running keduanya menunjukkan Yes, replikasi beroperasi secara normal.

Bagian berikutnya menjelaskan konfigurasi replikasi lanjutan, termasuk perbedaan antara replikasi asinkron dan semi-sinkron serta penyiapan menggunakan GTID.

4. Jenis Replikasi dan Penggunaan Lanjutan

Replikasi MySQL mencakup dua jenis utama berdasarkan metode sinkronisasi data: replikasi asinkron dan replikasi semi-sinkron. Dengan memahami karakteristiknya dan memilih sesuai kasus penggunaan Anda, Anda dapat meningkatkan kinerja sistem serta keandalannya. Bagian ini juga menjelaskan manfaat penggunaan GTID (Global Transaction Identifier) untuk konfigurasi replikasi.

Perbedaan Antara Replikasi Asinkron dan Semi‑Sinkron

1. Replikasi Asinkron

Dalam replikasi asinkron, server master mengembalikan respons ke klien segera setelah menyelesaikan transaksi. Dengan kata lain, master dapat terus memproses permintaan baru meskipun sinkronisasi ke server slave tertunda. Hal ini memberikan kinerja respons yang sangat baik dan cocok untuk sistem yang berfokus pada distribusi beban. Namun, saat terjadi kegagalan, ada risiko data yang belum diterapkan ke server slave dapat hilang.

2. Replikasi Semi‑Sinkron

In semi-synchronous replication, server master mengembalikan respons ke klien hanya setelah memastikan bahwa transfer data ke server slave telah selesai. Ini meningkatkan konsistensi data, tetapi karena menunggu slave, waktu respons transaksi dapat meningkat. Replikasi semi-sinkron sangat cocok untuk sistem yang memerlukan konsistensi data tinggi atau lingkungan di mana keandalan data menjadi prioritas utama.

Replikasi Menggunakan GTID

GTID (Global Transaction Identifier) memberikan ID unik untuk setiap transaksi dan menjaga konsistensi transaksi antara master dan slave. Mengaktifkan GTID membuat manajemen replikasi lebih mudah dibandingkan dengan replikasi tradisional berbasis posisi binary log.

Keuntungan GTID

  • Konsistensi Data yang Ditingkatkan : Dengan GTID, slave dapat secara otomatis mengidentifikasi transaksi yang belum diterapkan, sehingga lebih mudah menjaga konsistensi.
  • Manajemen Replikasi yang Disederhanakan : GTID meningkatkan efisiensi untuk failover, pergantian master/slave, dan tugas pemulihan. Karena Anda tidak lagi perlu menentukan posisi binary log, operasi menjadi lebih sederhana.

Konfigurasi Replikasi GTID

Untuk menggunakan GTID, Anda harus menambahkan dan mengaktifkan opsi berikut dalam file konfigurasi baik master maupun slave.

Konfigurasi Server Master

[mysqld]
server-id=1
log-bin=mysql-bin
gtid_mode=ON
enforce_gtid_consistency=ON

Konfigurasi Server Slave

[mysqld]
server-id=2
gtid_mode=ON
enforce_gtid_consistency=ON
read_only=ON

Dalam lingkungan yang mendukung GTID, replikasi dilakukan secara otomatis melalui GTID hanya dengan mengatur informasi master pada slave menggunakan perintah CHANGE MASTER TO.

Bagian berikut menjelaskan metode pemeliharaan untuk replikasi MySQL dan poin pemantauan kunci untuk manajemen operasional.

5. Pemeliharaan dan Pemantauan Replikasi

Untuk menjalankan replikasi MySQL dengan baik, pemeliharaan dan pemantauan rutin sangat penting. Bagian ini menjelaskan perintah untuk memeriksa apakah replikasi berfungsi normal dan cara menangani kesalahan umum.

Cara Memeriksa Status Replikasi

Gunakan perintah berikut untuk memeriksa status sinkronisasi antara master dan slave.

Memeriksa Status Master

Anda dapat memverifikasi status replikasi server master menggunakan perintah SHOW MASTER STATUS. Perintah ini menampilkan nama file binary log dan posisi saat ini, memungkinkan Anda mengonfirmasi pembaruan terbaru yang harus dikirim ke slave.

SHOW MASTER STATUS;

Output biasanya mencakup bidang-bidang berikut:

  • File : Nama file binary log saat ini yang dihasilkan oleh master
  • Position : Posisi saat ini dalam binary log
  • Binlog_Do_DB dan Binlog_Ignore_DB : Basis data yang termasuk/dikecualikan dari replikasi

Memeriksa Status Slave

Anda dapat memeriksa status replikasi server slave menggunakan perintah SHOW SLAVE STATUS. Hasilnya mencakup informasi yang diperlukan untuk menentukan apakah slave beroperasi dengan benar.

SHOW SLAVE STATUS\G;

Bidang kunci meliputi:

  • Slave_IO_Running dan Slave_SQL_Running : Jika keduanya Yes, slave berjalan normal.
  • Seconds_Behind_Master : Menunjukkan seberapa jauh slave tertinggal dari master (dalam detik). Idealnya, nilai ini harus 0.

Memecahkan Masalah Replikasi

Masalah umum selama operasi replikasi meliputi kesalahan koneksi dan inkonsistensi data. Berikut adalah contoh kasus kesalahan dan cara menanganinya.

1. Kesalahan Koneksi

Jika Slave_IO_Running bernilai No, berarti slave tidak dapat terhubung ke master. Coba langkah berikut:

  • Verifikasi nama host atau alamat IP master : Pastikan alamat master sudah benar.
  • Periksa pengaturan firewall : Pastikan port yang diperlukan (biasanya 3306) terbuka.

2. Inkonsistensi Data

Jika Last_Error berisi pesan error, mungkin terjadi inkonsistensi data antara master dan slave. Dalam kasus seperti itu, hentikan slave dan terapkan perbaikan sebelum memulai kembali replikasi.

STOP SLAVE;
# Restart after applying fixes
START SLAVE;

3. Mengurangi Lag Replikasi

Lag replikasi dapat disebabkan oleh keterbatasan perangkat keras slave atau masalah jaringan. Jika diperlukan, meningkatkan konfigurasi server slave dapat meningkatkan kinerja.

Bagian berikutnya mengeksplorasi masalah replikasi secara lebih detail dan memberikan solusi lebih lanjut.

6. Masalah Umum dan Solusinya

Selama operasi replikasi MySQL, berbagai masalah dapat muncul. Bagian ini menjelaskan masalah umum dan cara mengatasinya. Mendeteksi masalah lebih awal dan menerapkan perbaikan yang tepat membantu menjaga operasi sistem yang stabil.

1. Ketika Slave_IO_Running Berhenti

Gejala: Jika Slave_IO_Running menunjukkan No dalam output SHOW SLAVE STATUS, slave tidak dapat terhubung ke master.

Penyebab dan Solusi:

  • Masalah Jaringan : Jika ada masalah konektivitas jaringan, slave tidak dapat mengakses master. Periksa pengaturan firewall dan pastikan master dapat dijangkau.
  • Hostname atau Alamat IP Master yang Salah : Verifikasi bahwa hostname atau alamat IP yang ditentukan dalam CHANGE MASTER TO sudah benar.
  • Masalah Hak Istimewa Pengguna : Jika pengguna replikasi pada master tidak memiliki hak istimewa yang cukup, koneksi akan gagal. Pastikan hak istimewa yang tepat telah diberikan menggunakan GRANT REPLICATION SLAVE .

2. Inkonsistensi Data pada Slave

Gejala: Jika data tidak cocok antara master dan slave, slave dapat masuk ke keadaan tidak konsisten.

Penyebab dan Solusi:

  • Koreksi Data Manual : Hentikan slave, perbaiki transaksi yang bermasalah secara manual, lalu mulai kembali replikasi. STOP SLAVE; # Perbaiki data jika diperlukan START SLAVE;
  • Resinkronisasi : Jika inkonsistensi berskala besar, ambil backup penuh dari master dan sinkronkan kembali slave.

3. Penundaan Replikasi

Gejala: Jika Seconds_Behind_Master tidak 0 dalam output SHOW SLAVE STATUS, slave tertinggal dari master. Idealnya, nilai ini harus sedekat mungkin dengan 0.

Penyebab dan Solusi:

  • Keterbatasan Perangkat Keras Slave : Jika server slave memiliki sumber daya yang tidak cukup, ia mungkin tidak dapat mengikuti. Meningkatkan perangkat keras dapat efektif.
  • Optimisasi Kueri : Jika kueri yang diterima dari master memakan waktu terlalu lama untuk dieksekusi pada slave, penundaan replikasi dapat terjadi. Menambahkan indeks dan mengoptimalkan kueri dapat mengurangi waktu pemrosesan.

4. Kesalahan Izin Pengguna Replikasi

Gejala: Jika Last_Error menampilkan pesan terkait izin, slave mungkin tidak memiliki hak istimewa yang cukup untuk terhubung ke master.

Penyebab dan Solusi:

  • Konfigurasi Ulang Hak Istimewa Pengguna : Pastikan ada pengguna dengan hak istimewa yang sesuai pada master. Konfigurasikan ulang jika diperlukan. GRANT REPLICATION SLAVE ON *.* TO 'repl'@'slave_ip_address'; FLUSH PRIVILEGES;

5. Pertumbuhan Binary Log

Gejala: Binary log pada master dapat tumbuh berlebihan, mengonsumsi ruang disk.

Penyebab dan Solusi:

  • Rotasi Binary Log : Secara rutin hapus atau arsipkan binary log untuk mencegah pertumbuhan berlebihan. Dengan mengonfigurasi expire_logs_days, Anda dapat secara otomatis menghapus log yang lebih lama dari periode tertentu. SET GLOBAL expire_logs_days = 7; # Hapus log yang lebih lama dari 7 hari

Dengan memahami masalah replikasi MySQL umum ini dan solusinya, Anda dapat memastikan manajemen operasional yang lebih lancar. Bagian berikutnya merangkum poin-poin kunci untuk manajemen replikasi.

7. Kesimpulan

MySQL replication adalah fitur penting untuk meningkatkan konsistensi data dan keandalan sistem. Dalam artikel ini, kami membahas segala hal mulai dari konsep dasar replikasi MySQL hingga prosedur penyiapan, praktik pemantauan, dan metode pemecahan masalah. Di bawah ini adalah ringkasan poin-poin utama untuk manajemen replikasi yang efektif.

Ringkasan Utama

  1. Memilih Jenis Replikasi yang Tepat
  • Replikasi asinkron memberikan waktu respons yang lebih cepat dan ideal untuk distribusi beban. Namun, jika keandalan menjadi prioritas, replikasi semi-sinkron lebih cocok. Pilih berdasarkan kebutuhan sistem Anda.
  1. Penggunaan GTID yang Efektif
  • GTID menghilangkan kebutuhan untuk menentukan posisi binary log dan memungkinkan manajemen transaksi yang mulus. Ini sangat berguna di lingkungan dengan banyak slave atau di mana failover sangat penting.
  1. Pemantauan Status Secara Berkala
  • Gunakan SHOW MASTER STATUS dan SHOW SLAVE STATUS untuk secara rutin memantau keadaan operasional server master dan slave. Tindakan cepat saat mendeteksi anomali meminimalkan risiko seperti inkonsistensi data atau lag.
  1. Menguasai Pemecahan Masalah Dasar
  • Masalah replikasi yang umum meliputi kesalahan koneksi slave, inkonsistensi data, dan lag. Memahami solusi dasar untuk setiap masalah memastikan operasi yang lebih lancar.
  1. Manajemen Binary Log
  • Karena binary log dapat mengonsumsi ruang disk yang signifikan, disarankan untuk mengonfigurasi expire_logs_days untuk pembersihan otomatis dan melakukan pemeliharaan secara rutin.

Replikasi MySQL bukan tugas penyiapan satu kali. Pemantauan terus-menerus dan pemeliharaan yang tepat sangat penting. Dengan secara rutin meninjau status sistem dan menyesuaikan konfigurasi bila diperlukan, Anda dapat membangun dan memelihara sistem basis data yang sangat andal.

Kami berharap panduan ini membantu Anda lebih memahami dan mengimplementasikan replikasi MySQL. Semoga operasi replikasi Anda berjalan lancar dan stabil.