Replika baca di Azure Database for MySQL

  • Artikel

BERLAKU UNTUKAzure Database for MySQL - Server Tunggal

Penting

Server tunggal Azure Database for MySQL berada di jalur penghentian. Kami sangat menyarankan Agar Anda meningkatkan ke server fleksibel Azure Database for MySQL. Untuk informasi selengkapnya tentang migrasi ke server fleksibel Azure Database for MySQL, lihat Apa yang terjadi pada Server Tunggal Azure Database for MySQL?

Fitur replika baca memungkinkan Anda mereplikasi data dari server Azure Database for MySQL ke server baca-saja. Anda dapat mereplikasi dari server sumber maksimal lima replika. Replika diperbarui secara asinkron menggunakan teknologi replikasi berbasis posisi file log biner (binlog) native mesin MySQL. Untuk mempelajari selengkapnya tentang replikasi binlog, lihat ringkasan replikasi binlog MySQL.

Replika adalah server baru yang Anda kelola hampir sama dengan server Azure Database for MySQL biasa. Untuk setiap replika baca, Anda akan ditagih atas komputasi yang disediakan dalam vCore dan penyimpanan dalam GB/bulan.

Untuk mempelajari selengkapnya tentang fitur dan masalah replikasi MySQL, lihat dokumentasi replikasi MySQL.

Catatan

Artikel ini berisi referensi ke istilah slave, istilah yang tidak lagi digunakan Microsoft. Saat istilah dihapus dari perangkat lunak, kami akan menghapusnya dari artikel ini.

Kapan harus menggunakan replika baca

Fitur replika baca membantu meningkatkan performa dan skala beban kerja intensif baca. Beban kerja baca dapat diisolasi ke replika, sedangkan beban kerja tulis dapat diarahkan ke sumbernya.

Skenario umum adalah meminta BI dan beban kerja analitis menggunakan replika baca sebagai sumber data untuk pelaporan.

Karena bertuliskan baca-saja, replika tidak secara langsung mengurangi beban kapasitas tulis pada sumbernya. Fitur ini tidak ditargetkan pada beban kerja tulis yang intensif.

Fitur replika baca menggunakan replikasi asinkron mySQL. Fitur ini tidak dimaksudkan untuk skenario replikasi sinkron. Akan ada penundaan terukur antara sumber dan replika. Data pada replika akhirnya menjadi konsisten dengan data pada sumbernya. Gunakan fitur tersebut untuk beban kerja yang dapat mengakomodasi penundaan ini.

Replikasi lintas wilayah

Anda dapat membuat replika baca di wilayah yang berbeda dari server sumber. Replikasi lintas wilayah dapat membantu skenario seperti perencanaan pemulihan bencana atau mendekatkan data dengan pengguna Anda.

Anda dapat memiliki server sumber di wilayah Azure Database for MySQL mana pun. Server sumber dapat memiliki replika di wilayah pasangannya atau wilayah replika universal. Gambar berikut ini memperlihatkan wilayah replika mana yang tersedia bergantung pada wilayah sumber Anda.

Wilayah replika universal

Anda dapat membuat replika baca di salah satu wilayah berikut, terlepas dari lokasi server sumber Anda. Wilayah replika universal yang didukung meliputi:

Wilayah Ketersediaan replika
Australia Timur ✔️
Australia Tenggara ✔️
Brasil Selatan ✔️
Kanada Tengah ✔️
Kanada Timur ✔️
US Tengah ✔️
AS Timur ✔️
AS Timur 2 ✔️
Asia Timur ✔️
Jepang Timur ✔️
Jepang Barat ✔️
Korea Tengah ✔️
Korea Selatan ✔️
Eropa Utara ✔️
US Tengah Utara ✔️
US Tengah Selatan ✔️
Asia Tenggara ✔️
Swiss Utara ✔️
UK Selatan ✔️
UK Barat ✔️
AS Tengah Bagian Barat ✔️
US Barat ✔️
US Barat 2 ✔️
Eropa Barat ✔️
India Tengah* ✔️
Prancis Tengah* ✔️
UAE Utara* ✔️
Afrika Selatan Utara* ✔️

Catatan

*Wilayah tempat Azure Database for MySQL memiliki penyimpanan tujuan umum v2 di Pratinjau Umum
*Untuk wilayah Azure ini, Anda akan memiliki opsi untuk membuat server di penyimpanan tujuan Umum v1 dan v2. Untuk server yang dibuat dengan Penyimpanan tujuan umum v2 dalam pratinjau publik, Anda dibatasi untuk membuat server replika hanya di wilayah Azure yang mendukung penyimpanan tujuan umum v2.

Wilayah yang dipasangkan

Selain wilayah replika universal, Anda dapat membuat replika baca di wilayah berpasangan Azure di server sumber Anda. Jika tidak mengetahui pasangan wilayah Anda, Anda dapat mempelajari selengkapnya dari artikel Wilayah Berpasangan Azure.

Jika Anda menggunakan replika lintas wilayah untuk perencanaan pemulihan bencana, sebaiknya Anda membuat replika di wilayah yang dipasangkan, bukan di salah satu wilayah lainnya. Wilayah yang dipasangkan menghindari pembaruan simultan dan memprioritaskan isolasi fisik dan residensi data.

Namun, ada beberapa batasan untuk dipertimbangkan:

  • Ketersediaan regional: Azure Database for MySQL tersedia di Prancis Tengah, UAE Utara, dan Jerman Tengah. Namun, wilayah berpasangan mereka tidak tersedia.

  • Pasangan satu arah: Beberapa wilayah Azure dipasangkan dalam satu arah saja. Wilayah-wilayah tersebut mencakup India Barat, Brasil Selatan, dan US Gov Virginia. Ini berarti bahwa server sumber di India Barat dapat membuat replika di India Selatan. Namun, server sumber di India Selatan tidak dapat membuat replika di India Barat. Hal ini karena wilayah sekunder India Barat adalah India Selatan, tetapi wilayah sekunder India Selatan bukan India Barat.

Membuat replika

Penting

  • Fitur replika baca hanya tersedia untuk server Azure Database for MySQL di tingkat harga Tujuan Umum atau Memori yang Dioptimalkan. Pastikan server sumber berada di salah satu tingkat harga tersebut.
  • Jika server sumber Anda tidak memiliki server replika yang ada, server sumber mungkin memerlukan restart untuk mempersiapkan diri untuk replikasi tergantung pada penyimpanan yang digunakan (v1/v2). Harap pertimbangkan hidupkan ulang server dan lakukan operasi ini selama jam-jam sibuk. Lihat Memulai ulang Server Sumber untuk detail selengkapnya.

Saat Anda memulai alur kerja pembuatan replika, server Azure Database for MySQL Azure yang kosong akan dibuat. Server baru akan diisi dengan data yang ada di server sumber. Waktu pembuatan bergantung pada jumlah data pada sumber dan waktu sejak pencadangan penuh mingguan terakhir. Waktu dapat berkisar dari beberapa menit hingga beberapa jam. Server replika selalu dibuat dalam grup sumber daya yang sama dan langganan yang sama dengan server sumber. Jika ingin membuat server replika dalam grup sumber daya yang berbeda atau langganan yang berbeda, Anda dapat memindahkan server replika setelah pembuatan.

Setiap replika diaktifkan untuk penyimpanan yang bertambah secara otomatis. Fitur bertambah otomatis memungkinkan replika untuk mengikuti data yang direplikasi ke dalamnya, dan mencegah gangguan replikasi yang disebabkan oleh kesalahan kehabisan ruang penyimpanan.

Pelajari cara membuat replika baca di portal Azure.

Menghubungkan ke replika

Saat dibuat, replika akan mewarisi aturan firewall server sumber. Setelah itu, aturan ini akan terpisah dari server sumber.

Replika mewarisi akun admin dari server sumber. Semua akun pengguna di server sumber akan direplikasi ke replika baca. Anda hanya dapat tersambung ke replika baca menggunakan akun pengguna yang tersedia di server sumber.

Anda dapat menyambungkan ke replika menggunakan nama host dan akun pengguna yang valid, seperti yang Anda lakukan pada server Azure Database for MySQL biasa. Untuk server bernama myreplica dengan nama pengguna admin myadmin, Anda dapat tersambung ke replika menggunakan CLI mysql:

mysql -h myreplica.mysql.database.azure.com -u myadmin@myreplica -p

Di perintah, masukkan kata sandi untuk akun pengguna.

Pantau replikasi

Azure Database for MySQL menyediakan metrik jeda Replikasi dalam detik di Azure Monitor. Metrik ini hanya tersedia untuk replika. Metrik ini dihitung menggunakan metrik seconds_behind_master yang tersedia di perintah SHOW SLAVE STATUS MySQL. Atur pemberitahuan untuk memberi tahu Anda ketika jeda replikasi mencapai nilai yang tidak dapat diterima untuk beban kerja Anda.

Jika Anda melihat peningkatan jeda replikasi, lihat latensi replikasi pemecahan masalah untuk memecahkan masalah dan memahami kemungkinan penyebabnya.

Hentikan replikasi

Anda dapat menghentikan replikasi antara sumber dan replika. Setelah replikasi dihentikan antara server sumber dan replika baca, replika akan menjadi server mandiri. Data di server mandiri adalah data yang tersedia pada replika saat perintah hentikan replikasi dimulai. Server mandiri tidak mengejar ketinggalan dengan server sumber.

Jika Anda memilih untuk menghentikan replikasi pada replika, semua tautan ke sumber sebelumnya dan replika lainnya akan hilang. Tidak ada failover otomatis antara sumber dan replikanya.

Penting

Server mandiri tidak dapat dibuat menjadi replika lagi. Sebelum Anda menghentikan replikasi pada replika baca, pastikan replika memiliki semua data yang diperlukan.

Pelajari cara menghentikan replikasi pada replika.

Failover

Tidak ada failover otomatis antara server sumber dan replika.

Karena replikasi bersifat asinkron, ada jeda antara sumber dan replika. Jumlah lag dapat dipengaruhi oleh banyak faktor seperti seberapa berat beban kerja yang berjalan di server sumber dan latensi antar pusat data. Dalam kebanyakan kasus, lag replika berkisar antara beberapa detik hingga beberapa menit. Anda dapat melacak jeda replikasi yang sebenarnya menggunakan metrik Jeda Replika, yang tersedia untuk setiap replika. Metrik ini menunjukkan waktu sejak transaksi terakhir diputar ulang. Sebaiknya identifikasi jeda rata-rata Anda dengan mengamati jeda replika selama jangka waktu tertentu. Anda dapat mengatur pemberitahuan untuk jeda replika, sehingga jika berada di luar jangkauan yang diharapkan, tindakan dapat diambil.

Tip

Jika beralih ke replika, jeda pada saat Anda membatalkan replika dari sumber akan menunjukkan berapa banyak data yang hilang.

Setelah Anda memutuskan ingin beralih ke replika:

  1. Menghentikan replikasi pada replika
    Langkah ini diperlukan agar server replika dapat menerima penulisan. Sebagai bagian dari proses ini, server replika akan dilepas dari sumbernya. Setelah Anda memulai penghentian replikasi, proses backend biasanya akan selesai dalam waktu sekitar 2 menit. Lihat bagian menghentikan replikasi di artikel ini untuk memahami implikasi dari tindakan ini.

  2. Arahkan aplikasi Anda ke replika (sebelumnya)
    Setiap server memiliki string koneksi yang unik. Perbarui aplikasi Anda agar mengarah ke replika (mantan) dan bukan ke sumber.

Setelah aplikasi Anda berhasil memproses baca dan tulis, Anda telah menyelesaikan failover. Jumlah waktu henti pengalaman aplikasi Anda akan bergantung pada saat Anda mendeteksi masalah dan menyelesaikan langkah 1 dan 2 yang tercantum sebelumnya.

Pengidentifikasi transaksi global (GTID)

Pengidentifikasi transaksi global (GTID) adalah pengidentifikasi unik yang dibuat dengan setiap komitmen transaksi di server sumber dan NONAKTIF secara default di Azure Database for MySQL. GTID didukung pada versi 5.7 dan 8.0 dan hanya di server yang mendukung penyimpanan hingga 16 TB (penyimpanan Umum v2). Untuk mempelajari selengkapnya tentang GTID dan cara menggunakan replikasi, lihat dokumentasi replikasi MySQL dengan GTID.

MySQL mendukung dua jenis transaksi: Transaksi GTID (diidentifikasi dengan GTID) dan transaksi anonim (tidak memiliki GTID yang dialokasikan)

Parameter server berikut ini tersedia untuk mengonfigurasi GTID:

Parameter server Keterangan Nilai Default Nilai
gtid_mode Menunjukkan apakah GTID digunakan untuk mengidentifikasi transaksi. Perubahan antar mode hanya dapat dilakukan satu langkah dalam satu waktu dalam urutan menaik (mis. OFF ->OFF_PERMISSIVE ->ON_PERMISSIVE ->ON) OFF OFF: Transaksi baru dan replikasi harus anonim
OFF_PERMISSIVE: Transaksi baru bersifat anonim. Transaksi yang direplikasi dapat berupa transaksi anonim atau GTID.
ON_PERMISSIVE: Transaksi baru adalah transaksi GTID. Transaksi yang direplikasi dapat berupa transaksi anonim atau GTID.
ON: Baik transaksi baru maupun yang direplikasi harus berupa transaksi GTID.
enforce_gtid_consistency Memberlakukan konsistensi GTID dengan hanya mengizinkan pelaksanaan pernyataan yang dapat dicatat dengan cara yang aman secara transaksional. Nilai ini harus diatur ke ON sebelum mengaktifkan replikasi GTID. OFF OFF: Semua transaksi diizinkan untuk melanggar konsistensi GTID.
ON: Tidak ada transaksi yang diizinkan untuk melanggar konsistensi GTID.
WARN: Semua transaksi diizinkan untuk melanggar konsistensi GTID, tetapi peringatan akan dibuat.

Catatan

  • Setelah GTID diaktifkan, Anda tidak dapat menonaktifkannya. Jika perlu menonaktifkan GTID, Anda dapat menghubungi dukungan.

  • Pengubahan GTID dari satu nilai ke nilai lainnya hanya bisa dilakukan satu langkah pada satu waktu dalam urutan mode naik. Misalnya, jika gtid_mode saat ini ditetapkan ke OFF_PERMISSIVE, dimungkinkan untuk mengubah ke ON_PERMISSIVE tetapi tidak ke ON.

  • Agar replikasi tetap konsisten, Anda tidak dapat memperbaruinya untuk server master/replika.

  • Sebaiknya atur enforce_gtid_consistency ke ON sebelum Anda dapat mengatur gtid_mode=ON

Untuk mengaktifkan GTID dan mengonfigurasi perilaku konsistensi, perbarui parameter server gtid_mode dan enforce_gtid_consistencymenggunakan portal Azure, Azure CLI, atau PowerShell.

Jika GTID diaktifkan di server sumber (gtid_mode = AKTIF), replika yang baru saja dibuat juga akan mengaktifkan GTID dan menggunakan replikasi GTID. Untuk memastikan bahwa replikasi konsisten, gtid_mode tidak dapat diubah setelah master atau server replika dibuat dengan GTID diaktifkan.

Pertimbangan dan batasan

Tingkat harga

Replika baca saat ini hanya tersedia di tingkat harga Tujuan Umum dan Memori yang Dioptimalkan.

Catatan

Biaya menjalankan server replika didasarkan pada wilayah tempat server replika berjalan.

Pengaktifan ulang server sumber

Server yang memiliki penyimpanan tujuan umum v1,log_bin parameter akan TIDAK AKTIF secara default. Nilai akan diaktifkan saat Anda membuat replika baca pertama. Jika server sumber tidak memiliki server replika, sumber akan memulai ulang terlebih dahulu untuk mempersiapkan replikasi. Harap pertimbangkan hidupkan ulang server dan lakukan operasi ini selama jam-jam sibuk.

Server sumber yang memiliki penyimpanan tujuan Umum v2, log_bin parameter akan AKTIF secara default dan tidak memerlukan hidupkan ulang saat Anda menambahkan replika baca.

Replika baru

Replika baca dibuat sebagai server Azure Database for MySQL baru. Server yang sudah ada tidak dapat dibuat menjadi replika. Anda tidak dapat membuat replika atas replika baca lain.

Konfigurasi replika

Replika dibuat menggunakan konfigurasi server yang sama dengan sumbernya. Setelah replika dibuat, beberapa pengaturan dapat diubah secara independen dari server sumber: pembuatan komputasi, vCores, penyimpanan, dan periode retensi cadangan. Tingkat harga juga dapat diubah secara independen, kecuali ke atau dari tingkat Dasar.

Penting

Sebelum konfigurasi server sumber diperbarui ke nilai baru, perbarui konfigurasi replika ke nilai yang setara atau lebih besar. Tindakan ini memastikan replika dapat mengikuti perubahan apa pun yang dibuat pada sumbernya.

Aturan firewall dan pengaturan parameter diwariskan dari server sumber ke replika ketika replika dibuat. Kemudian, aturan replika bersifat independen.

Replika yang dihentikan

Jika Anda menghentikan replikasi antara server sumber dan replika baca, replika yang dihentikan akan menjadi server mandiri yang menerima baca dan tulis. Server mandiri tidak dapat dibuat menjadi replika lagi.

Server sumber dan mandiri yang dihapus

Ketika server sumber dihapus, replikasi pada semua replika baca akan dihentikan. Replika ini otomatis menjadi server mandiri dan dapat menerima pembacaan dan penulisan. Server sumber tersebut akan dihapus.

Akun pengguna

Pengguna di server sumber akan direplikasi ke replika baca. Anda hanya dapat tersambung ke replika baca menggunakan akun pengguna yang tersedia di server sumber.

Parameter server

Agar data tetap sinkron dan untuk menghindari potensi kerusakan atau kehilangan data, beberapa parameter server dikunci agar tidak diperbarui saat menggunakan replika baca.

Parameter server berikut dikunci pada server sumber dan replika:

Parameter event_scheduler dikunci pada server replika.

Untuk memperbarui salah satu parameter yang dikunci pada server utama, hapus server replika, perbarui nilai parameter yang ada di sumber, dan buat ulang replika.

GTID

GTID didukung pada:

  • MySQL versi 5.7 dan 8.0.
  • Server yang mendukung penyimpanan hingga 16 TB. Lihat artikel tingkat harga untuk mengetahui daftar lengkap wilayah yang mendukung penyimpanan 16 TB.

GTID NONAKTIF secara default. Setelah GTID diaktifkan, Anda tidak dapat menonaktifkannya. Jika perlu menonaktifkan GTID, Anda dapat menghubungi dukungan.

Jika GTID diaktifkan di server sumber, replika yang baru dibuat juga akan mengaktifkan GTID dan menggunakan replikasi GTID. Agar replikasi tetap konsisten, Anda tidak dapat memperbarui gtid_mode pada server sumber atau replika.

Lainnya

  • Membuat replika atas replika tidak didukung.
  • Tabel dalam memori dapat menyebabkan replika tidak sinkron. Ini adalah keterbatasan teknologi replikasi MySQL. Baca selengkapnya di dokumentasi referensi MySQL untuk informasi selengkapnya.
  • Pastikan tabel server sumber memiliki kunci primer. Kurangnya kunci utama dapat mengakibatkan latensi replikasi antara sumber dan replika.
  • Tinjau daftar lengkap batasan replikasi MySQL dalam dokumentasi MySQL

Langkah berikutnya