Membaca replika di Azure Database for MySQL

MySQL adalah salah satu mesin database populer untuk menjalankan aplikasi web dan seluler skala internet. Banyak pelanggan menggunakan Azure Database for MySQL untuk berbagai aplikasi, termasuk pendidikan online, streaming video, pembayaran digital, e-niaga, game, portal berita, pemerintah, dan situs web layanan kesehatan. Layanan ini harus dapat melayani dan menskalakan saat lalu lintas di web atau aplikasi seluler meningkat.

Di sisi aplikasi, pengembang biasanya menggunakan Java atau PHP. Mereka memigrasikan aplikasi untuk berjalan pada Azure Virtual Machine Scale Sets, Azure App Services, atau kontainerisasi untuk dijalankan di Azure Kubernetes Service (AKS). Dengan Virtual Machine Scale Set, App Service, atau AKS sebagai infrastruktur yang mendasar, penskalaan aplikasi disederhanakan dengan menyediakan VM baru secara instan dan mereplikasi komponen aplikasi stateless untuk memenuhi permintaan. Namun, database sering menjadi hambatan sebagai komponen stateful terpusat.

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

Anda mengelola replika sebagai server baru, sama seperti instans Server Fleksibel Azure Database for MySQL sumber Anda. Anda dikenakan biaya penagihan untuk setiap replika baca berdasarkan komputasi yang disediakan di vCore dan penyimpanan dalam GB per bulan. Untuk informasi selengkapnya, lihat Harga.

Fitur replika baca hanya tersedia untuk instans Azure Database for MySQL Flexible Server di tingkat harga Tujuan Umum atau Bisnis Kritis. Pastikan server sumber berada di salah satu tingkat harga tersebut.

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. Ketika kami menghapus istilah dari perangkat lunak, kami menghapusnya dari artikel ini.

Kasus penggunaan umum untuk replika baca

Fitur replika baca membantu Anda meningkatkan performa dan skala beban kerja intensif baca. Anda dapat mengisolasi beban kerja baca ke replika, sambil mengarahkan beban kerja tulis ke sumbernya.

Skenario umum meliputi:

• Menskalakan beban kerja baca yang berasal dari aplikasi dengan menggunakan proksi koneksi ringan seperti ProxySQL atau menggunakan pola berbasis layanan mikro untuk menskalakan kueri baca Anda yang berasal dari aplikasi untuk membaca replika
• Menggunakan replika baca sebagai sumber data untuk BI atau beban kerja pelaporan analitis
• Menyerap informasi telemetri ke dalam mesin database MySQL saat menggunakan beberapa replika baca untuk pelaporan data dalam skenario IoT atau Manufaktur

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. 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. Server Fleksibel Azure Database for MySQL memungkinkan Anda menyediakan replika baca di wilayah yang didukung Azure tempat Azure Database for MySQL Flexible Server tersedia. Dengan menggunakan fitur ini, server sumber dapat memiliki replika di wilayah yang dipasangkan atau wilayah replika universal. Lihat di sini untuk menemukan daftar wilayah Azure tempat Azure Database for MySQL Flexible Server tersedia hari ini.

Membuat replika

Saat Anda memulai alur kerja buat replika, Anda membuat instans Azure Database for MySQL Flexible Server kosong. Server baru berisi 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.

Catatan

Anda membuat replika baca dengan konfigurasi server yang sama dengan sumbernya. Anda dapat mengubah konfigurasi server replika setelah pembuatan. Anda selalu membuat server replika di grup sumber daya dan langganan yang sama dengan server sumber. Jika Anda ingin membuat server replika di grup sumber daya yang berbeda atau langganan yang berbeda, Anda dapat memindahkan server replika setelah pembuatan. Pertahankan konfigurasi server replika pada nilai yang sama atau lebih besar dari sumbernya untuk memastikan replika dapat mengikuti sumbernya.

Pelajari cara membuat replika baca di portal Azure.

Menghubungkan ke replika

Saat Anda membuat replika, replika mewarisi metode konektivitas server sumber. Anda tidak dapat mengubah metode konektivitas replika. Misalnya, jika server sumber menggunakan Akses privat (Integrasi VNet), replika tidak dapat menggunakan Akses publik (alamat IP yang diizinkan).

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 dengan menggunakan akun pengguna yang tersedia di server sumber.

Anda dapat terhubung ke replika dengan menggunakan nama host dan akun pengguna yang valid, seperti yang Anda lakukan pada instans Azure Database for MySQL Flexible Server reguler. Untuk server bernama myreplica dengan nama pengguna admin myadmin, Anda dapat terhubung ke replika dengan menggunakan MySQL CLI:

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

Di perintah, masukkan kata sandi untuk akun pengguna.

Pantau replikasi

Database Azure untuk Server Fleksibel MySQL menyediakan metrik Lag replikasi dalam hitungan detik di Azure Monitor. Metrik ini hanya tersedia untuk replika. Azure Monitor menghitung metrik ini dengan menggunakan seconds_behind_master metrik dalam perintah MySQL SHOW SLAVE STATUS . Atur pemberitahuan untuk memberi tahu Anda saat lag replikasi melebihi ambang batas 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.

Penting

Read Replica menggunakan teknologi replikasi berbasis penyimpanan, yang tidak lagi menggunakan SLAVE_IO_RUNNING/REPLICA_IO_RUNNING metrik yang tersedia dalam perintah MySQL.SHOW SLAVESTATUS'/'SHOWREPLICA STATUS Nilai ini selalu ditampilkan sebagai "Tidak" dan bukan menunjukkan status replikasi. Untuk mengetahui status replikasi yang benar, lihat metrik replikasi - Status Replika IO dan Status Replika SQL di bawah halaman Pemantauan.

Hentikan replikasi

Anda dapat menghentikan replikasi antara server sumber dan server replika. Ketika Anda menghentikan replikasi antara server sumber dan replika baca, server replika menjadi server mandiri. Server mandiri berisi data yang tersedia di server replika saat Anda memulai perintah hentikan replikasi. Server mandiri tidak menyinkronkan data yang hilang dari server sumber.

Ketika Anda menghentikan replikasi ke server replika, server replika kehilangan semua tautan ke server sumber sebelumnya dan ke server replika lainnya. Tidak ada failover otomatis antara server sumber dan server replikanya.

Penting

Anda tidak dapat mengonversi server mandiri kembali ke server replika. Sebelum Anda menghentikan replikasi pada replika baca, pastikan server replika memiliki semua data yang Anda butuhkan.

Untuk informasi selengkapnya, lihat menghentikan replikasi ke replika.

Pengalihan Cadangan

Tidak ada failover otomatis antara server sumber dan replika.

Replika baca menskalakan beban kerja intensif baca dan tidak menyediakan ketersediaan tinggi untuk server. Anda melakukan failover manual dengan menghentikan replikasi pada replika baca dengan membuatnya online dalam mode baca-tulis.

Karena replikasi asinkron, ada jeda antara sumber dan replika. Banyak faktor memengaruhi jumlah jeda, seperti beban kerja di server sumber dan latensi antara pusat data. Dalam kebanyakan kasus, jeda replika berkisar antara beberapa detik hingga beberapa menit. Anda dapat melacak lag replikasi Anda yang sebenarnya dengan menggunakan metrik Lag Replika , yang tersedia untuk setiap replika. Metrik ini menunjukkan waktu sejak transaksi terakhir diputar ulang. Kami menyarankan agar Anda mengidentifikasi lag rata-rata Anda dengan mengamati jeda replika Anda dari waktu ke waktu. Anda dapat mengatur pemberitahuan untuk jeda replika, sehingga jika berada di luar jangkauan yang diharapkan, tindakan dapat diambil.

Petunjuk / Saran

Jika Anda melakukan failover ke replika, jeda pada saat Anda membatalkan tautan replika dari sumber menunjukkan berapa banyak data yang hilang.

Setelah Anda memutuskan untuk melakukan failover ke replika:

1. Menghentikan replikasi pada replika

   Anda perlu menghentikan replikasi untuk membuat server replika dapat menerima tulisan. Proses ini mendelegasikan server replika dari sumbernya. Setelah Anda memulai replikasi berhenti, proses backend biasanya membutuhkan waktu sekitar dua menit untuk diselesaikan. 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.

Ketika aplikasi Anda berhasil memproses baca dan tulis, Anda menyelesaikan failover. Jumlah waktu henti yang dialami aplikasi Anda bergantung pada saat Anda mendeteksi masalah dan menyelesaikan langkah 1 dan 2.

Pengidentifikasi transaksi global (GTID)

Pengidentifikasi transaksi global (GTID) adalah pengidentifikasi unik yang dibuat server sumber dengan setiap transaksi yang dilakukan. Server Fleksibel Azure Database for MySQL menonaktifkan GTID secara default. Versi 5.7 dan 8.0 mendukung GTID. Untuk informasi selengkapnya tentang GTID dan cara replikasi menggunakannya, lihat Dokumentasi replikasi MySQL dengan GTID.

Gunakan parameter server berikut untuk mengonfigurasi GTID:

Parameter server	Deskripsi	Nilai Default	Nilai
gtid_mode	Menunjukkan apakah GTID digunakan untuk mengidentifikasi transaksi. Perubahan antar mode hanya dapat dilakukan satu langkah pada satu waktu dalam urutan naik (mis., OFF - ->OFF_PERMISSIVEON_PERMISSIVE> -)>ON	OFF*	OFF: Baik transaksi baru maupun replikasi harus bersifat 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. Atur nilai 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

Untuk instans Server Fleksibel Azure Database for MySQL yang mengaktifkan fitur Ketersediaan tinggi, nilai default diatur ke ON.

Setelah mengaktifkan GTID, Anda tidak dapat menonaktifkannya. Jika Anda perlu menonaktifkan GTID, hubungi dukungan.

Anda dapat mengubah GTID dari satu nilai ke nilai lainnya hanya satu langkah pada satu waktu dalam urutan mode naik. Misalnya, jika gtid_mode saat ini diatur ke OFF_PERMISSIVE, Anda dapat mengubahnya menjadi ON_PERMISSIVE tetapi tidak ke ON.

Agar replikasi tetap konsisten, Anda tidak dapat memperbaruinya untuk server utama atau replika.

Atur enforce_gtid_consistency ke ON sebelum mengatur gtid_mode ke ON.

Untuk mengaktifkan GTID dan mengonfigurasi perilaku konsistensi, perbarui gtid_mode parameter server dan enforce_gtid_consistency . Gunakan Konfigurasi parameter server di Azure Database for MySQL - Server Fleksibel menggunakan portal Microsoft Azure atau Konfigurasikan parameter server di Azure Database for MySQL - Server Fleksibel menggunakan Azure CLI.

Jika server sumber mengaktifkan GTID (gtid_mode = ON), replika yang baru dibuat juga mengaktifkan GTID dan menggunakan replikasi GTID. Untuk memastikan konsistensi replikasi, Anda tidak dapat mengubah gtid_mode setelah membuat server utama atau replika dengan GTID diaktifkan.

Pertimbangan dan batasan

Skenario	Batasan/Pertimbangan
Replika pada server di Tingkat Harga yang Dapat Melonjak	Tidak didukung
Harga	Biaya menjalankan server replika tergantung pada wilayah tempat server replika berjalan.
Waktu henti/hidupkan ulang server sumber	Tidak diperlukan hidupkan ulang atau waktu henti saat membuat replika baca. Operasi ini adalah operasi online.
Replika baru	Anda membuat replika baca sebagai instans Azure Database for MySQL Flexible Server baru. Anda tidak dapat membuat server yang ada ke dalam replika. Anda tidak dapat membuat replika atas replika baca lain.
Konfigurasi replika	Anda membuat replika dengan menggunakan konfigurasi server yang sama dengan sumbernya. Setelah membuat replika, Anda dapat mengubah beberapa pengaturan secara independen dari server sumber: pembuatan komputasi, vCore, penyimpanan, dan periode retensi cadangan. Anda juga dapat mengubah tingkat komputasi secara independen. PENTING - Sebelum Anda memperbarui konfigurasi server sumber ke nilai baru, perbarui konfigurasi replika ke nilai yang sama atau lebih besar. Tindakan ini memastikan replika dapat mengikuti perubahan apa pun yang dibuat pada sumbernya. Metode konektivitas dan pengaturan parameter diwarisi dari server sumber ke replika saat Anda membuat replika. 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. Anda tidak dapat membuat server mandiri menjadi replika lagi.
Server sumber yang dihapus	Saat Anda menghapus server sumber, replikasi berhenti ke semua replika baca. 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 dengan 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: - innodb_file_per_table - log_bin_trust_function_creators Parameter event_scheduler dikunci pada server replika. Untuk memperbarui salah satu parameter sebelumnya di server sumber, hapus server replika, perbarui nilai parameter pada sumber, dan buat ulang replika.
Parameter tingkat sesi	Saat mengonfigurasi parameter tingkat sesi seperti 'foreign_keys_checks' pada replika baca, pastikan nilai parameter yang Anda tetapkan pada replika baca konsisten dengan server sumber.
Menambahkan kolom Kunci Primer AUTO_INCREMENT ke tabel yang ada di server sumber	Kami tidak menyarankan untuk mengubah tabel setelah AUTO_INCREMENT membuat replika baca, karena tindakan ini merusak replikasi. Jika Anda ingin menambahkan kolom kenaikan otomatis setelah membuat server replika, pertimbangkan pendekatan berikut: - Buat tabel baru dengan skema yang sama dengan tabel yang ingin Anda ubah. Dalam tabel baru, ubah kolom dengan AUTO_INCREMENT, lalu pulihkan data dari tabel asli. Letakkan tabel lama dan ganti namanya di sumber; Pendekatan ini tidak memerlukan penghapusan server replika, tetapi mungkin dikenakan biaya penyisipan besar untuk membuat tabel cadangan. - Buat ulang replika setelah menambahkan semua kolom kenaikan otomatis.
Lainnya	- Membuat replika replika tidak didukung. - Tabel dalam memori dapat menyebabkan replika menjadi tidak sinkron. Batasan ini disebabkan oleh teknologi replikasi MySQL. Untuk informasi selengkapnya, lihat dokumentasi referensi MySQL. - Pastikan tabel server sumber memiliki kunci utama. Kurangnya kunci primer dapat mengakibatkan latensi replikasi antara sumber dan replika. - Tinjau daftar lengkap batasan replikasi MySQL dalam dokumentasi MySQL.

Konten terkait

• Membuat dan mengelola replika baca dengan menggunakan portal Microsoft Azure
• Membuat dan mengelola replika baca dengan menggunakan Azure CLI