May 29, 2021 - 4 ' read

Tentang Replikasi Eksternal dari dan ke MySQL Google CloudSQL

database, cloud, gcp, mysql, infrastructure

Penulis ingin mengawali catatan kali ini dengan kisah jenaka, betapa lucunya peraturan negeri ini mengenai pusat data untuk industri finansial, tapi takut dan mungkin nirfaedah. Semoga seseorang yang bekerja di bidang yang sama, nanti, akan mampu menuliskan betapa jenakanya peraturan tersebut.

Ya, meski kita tahu di Google CloudSQL (baik postgresql maupun mysql) kita dapat membuat replika, namun oleh karena aturan bahwa sebuah perusahaan yang bergerak di bidang finansial, harus membuat pusat data untuk pemulihan bencana (Disaster Recovery Data Center), maka pada kasus ini, penulis dan tim infrastruktur, ditugaskan untuk mempersiapkan sebuah set komplit pada pusat data lain. Karena pusat data DR, maka harus selain Google Cloud Platform (sudah dipakai sebagai pusat data utama), bisa saja di sebuah VM di penyedia lain, seperti Alibaba Cloud, Biznet Gio/Neo atau merek lain. Pada aktivitas ini, komponen yang paling menjadi sorotan adalah klaster basis data, dalam hal ini MySQL Database Cluster.

Tulisan ini tidak akan menjelaskan langkah per langkah, namun hanya merekam hal penting yang mungkin nanti akan membantu penulis kembali, jika menemui hal yang sama ke depannya. Pada tulisan ini, versi MySQL yang penulis gunakan adalah versi 8.0. Untuk detail petunjuk, akan penulis lampirkan tautan referensi di akhir artikel. Pada aspek yang lebih detil, penulis berkonsultasi dengan rekan ahli lainnya, yaitu Hofid Mashudi dan Agus Syafaat (terima kasih teman temanku) * gestur saranghaeyo *.

Replikasi ke Replika Eksternal #

Pada skenario ini, kita akan mempunyai MySQL primary instance di Google CloudSQL sedangkan untuk replica instances ada di CloudSQL sendiri dan sebuah VM (sebuah VM berisi MySQL yang dipasang dan dikonfigurasi sendiri tanpa managed service).

mysql vm replica ---- mysql cloudsql primary 
                         -- cloudsql replica

Selain membuat MySQL di Google CloudSQL dan VM, langkah - langkahnya secara garis besar adalah sebagai berikut :

Membuat 1 user untuk replikasi dengan permission REPLICATION SLAVE atau REPLICATION CLIENT pada primary instance di CloudSQL
Memastikan antara VM replica dan CloudSQL dapat berkomunikasi di port 3306
Ekpor data dari primary instance (CloudSQL) dengan mempertahankan GTID
Impor data dari hasil ekspor di atas ke replika di VM
Menyalin server certificate dari primary instance di CloudSQL ke VM replica.
Set master di VM replica dengan contoh CHANGE MASTER TO MASTER_HOST = '', MASTER_PORT = 3306, MASTER_USER = '', MASTER_PASSWORD = '<replica user's password>, MASTER_AUTO_POSITION = 1, MASTER_SSL = 1, MASTER_SSL_CA = '/path/to/server-ca.pem';
START REPLICA dijalankan di VM replica

Cukup simpel dan tidak berbelit. Namun ada beberapa hal yang perlu diperhatikan pula. Pada kasus ini, kita harus memastikan replication-ignore-db pada replika eksternal harus dapat diset dan dipasang mysql sebagai nilainya. replication-ignore-db = mysql. Sehingga, jika kita ingin melakukan replikasi misalkan antara mysql di cloudsql dan amazon RDS, kita harus pastikan dulu RDS support setup parameter ini atau tidak, jika tidak, maka replikasi tak dapat dilakukan. [1]

Hal lain, adalah memastikan parameter read_only di set ke ON , pada replika. Jika perlu, setelah setup selesai, kita set super_read_only untuk menghindari “errant transaction” [2]

Replikasi dari Eksternal (External Master/Primary) #

Salah satu aspek penilaian auditor terhadap kesiapan sistem, pada produk - produk teknologi finansial (tekfin / fintech) salah satunya adalah data center swing atau secara sederhana, melakukan simulasi jika terjadi bencana, dan pusat data cadangan akan menjadi yang utama. Dari sisi database, maka hal ini sesederhana membalik skenario di atas dari cloudsql sebagai primary instance dan VM sebagai replika. Sehingga VM sekarang sebagai primary instance sedangkan mysql di CloudSQL menjadi replika. Prosedur lengkap ada di referensi bawah [3], namun secara ringkas dapat ditulis sebagai berikut :

Membuat 1 user untuk replikasi dengan permission REPLICATION SLAVE atau REPLICATION CLIENT pada VM mysql replika
Membuat “_ source representation _” pada Google CloudSQL [4]
Melakukan prosedur demote pada mysql instance di CloudSQL (yang tadinya adalah primary)
eksekusi STOP REPLICA dan RESET REPLICA ALL pada mysql di VM (yang saat ini jadi master)
set parameter read_only (dan super_read_only) menjadi OFF pada mysql di VM

Sesederhana itu. Pada aktivitas ini, yang paling harus diperhatikan adalah pada saat pembuatan source representation dan prosedur demotion , untuk :

memastikan memasukkan server certificate milik mysql di VM dengan tepat
memastikan mysql di CloudSQL tidak punya CLoudSQL replica lagi. [5]

Jika terdapat replika pada sisi CloudSQL, maka yang terjadi, akan ada return error seperti ini :

{
  "error": {
    "code": 400,
    "message": "The requested operation is not valid for an instance that has a replica.",
    "errors": [
      {
        "message": "The requested operation is not valid for an instance that has a replica.",
        "domain": "global",
        "reason": "badRequest"
      }
    ]
  }
}

Monitoring #

Pada kedua aktivitas di atas, pastikan kondisi replikasi selalu dalam pantauan.

Tetap memantau Second Behind Source tetap 0 di hasil output dari perintah SHOW REPLICA STATUS\G
Cek kondisi replika dari sisi primary instance SHOW SLAVE HOSTS
Cek GTID di SHOW MASTER STATUS
Jika memungkinkan, pantau metrik ini pada kakas pemantauan (monitoring tools) seperti Grafana + Prometheus atau Stackdriver Monitoring atau AWS Cloudwatch atau Datadog dll.
Pastikan retensi binlog pada primary instance dihitung dengan benar disesuaikan kebutuhan replikasi dan kondisi network

Jika ada yang pertanyaan atau masukan, dengan senang hati dapat berdikusi di kontak[at]robee.id.

* nonton drakor lagi *

Referensi: #

Post image by Kelly Sikkema on Unsplash