Bagikan melalui

Replika baca di Database Azure untuk MySQL - Server Fleksibel

  • Artikel

BERLAKU UNTUK: Azure Database for MySQL - Server Fleksibel

MySQL adalah salah satu mesin database populer untuk menjalankan aplikasi web dan seluler skala internet. Banyak pelanggan kami menggunakannya untuk layanan pendidikan online, layanan streaming video, solusi pembayaran digital, platform e-commerce, layanan game, portal berita, pemerintah, dan situs web pelayanan kesehatan. Layanan ini diperlukan untuk melayani dan menskalakan seiring meningkatnya lalu lintas di web atau aplikasi seluler.

Di sisi aplikasi, aplikasi biasanya dikembangkan di Java atau PHP dan dimigrasikan untuk berjalan pada Azure Virtual Machine Scale Sets atau Azure App Services atau dikontainerisasi untuk berjalan 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 tetapi seringkali, database akhirnya 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 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 mirip dengan 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/bulan. Untuk informasi selengkapnya, lihat Harga.

Catatan

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. Saat istilah dihapus dari perangkat lunak, kami akan menghapusnya dari artikel ini.

Kasus penggunaan umum untuk 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 yang umum adalah:

  • Menskalakan beban kerja baca yang berasal dari aplikasi dengan menggunakan proxy koneksi ringan seperti ProxySQL atau menggunakan pola berbasis layanan mikro untuk memperkecil kueri baca yang berasal dari aplikasi untuk membaca replika
  • Beban kerja pelaporan BI atau analitik dapat menggunakan replika baca sebagai sumber data untuk pelaporan
  • Untuk skenario IoT atau Manufaktur di mana informasi telemetri diserap ke dalam mesin database MySQL sementara beberapa replika baca digunakan untuk pelaporan data

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. Silakan lihat di sini untuk menemukan daftar wilayah Azure tempat Azure Database for MySQL Flexible Server tersedia hari ini.

Membuat replika

Jika server sumber tidak memiliki server replika yang ada, sumber pertama-tama memulai ulang untuk mempersiapkan dirinya sendiri untuk replikasi.

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

Catatan

Replika baca dibuat dengan konfigurasi server yang sama dengan sumbernya. Konfigurasi server replika dapat diubah setelah dibuat. 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. Sebaiknya konfigurasi server replika disimpan dengan 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

Pada saat pembuatan, replika akan mewarisi metode konektivitas dari server sumber. Anda tidak dapat mengubah metode konektivitas replika. Misalnya jika server sumber memiliki akses Privat (Integrasi VNet) maka replika tidak dapat berada di 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 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 tersambung ke replika menggunakan CLI mysql:

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. 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.

Penting

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

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.

Replika baca dimaksudkan untuk penskalaan beban kerja intensif baca dan tidak dirancang untuk memenuhi kebutuhan ketersediaan server yang tinggi. Menghentikan replikasi pada replika baca untuk membuatnya online dalam mode baca tulis adalah cara untuk melakukan failover manual ini.

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 Anda melakukan failover ke replika, jeda pada saat Anda mendelegasikan replika dari sumber menunjukkan berapa banyak data yang hilang.

Setelah Anda memutuskan ingin melakukan failover ke replika:

  1. Menghentikan replikasi pada replika
    Langkah ini diperlukan agar server replika dapat menerima penulisan. Sebagai bagian dari proses ini, server replika didelink 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 yang dialami aplikasi Anda bergantung pada saat Anda mendeteksi masalah dan menyelesaikan langkah 1 dan 2 di atas.

Pengidentifikasi transaksi global (GTID)

Pengidentifikasi transaksi global (GTID) adalah pengidentifikasi unik yang dibuat dengan setiap transaksi yang dilakukan di server sumber dan NONAKTIF secara default di Server Fleksibel Azure Database for MySQL. GTID didukung pada versi 5.7 dan 8.0. Untuk mempelajari selengkapnya tentang GTID dan cara menggunakan replikasi, lihat dokumentasi replikasi MySQL dengan GTID.

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: 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. 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.

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

Catatan

  • Setelah GTID diaktifkan, Anda tidak dapat menonaktifkannya. Jika perlu menonaktifkan GTID, Anda dapat menghubungi 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, dimungkinkan untuk mengubah ke ON_PERMISSIVE tetapi tidak ke AKTIF.
  • Agar replikasi tetap konsisten, Anda tidak dapat memperbaruinya untuk server master/replika.
  • Disarankan untuk MENGATUR enforce_gtid_consistency ke AKTIF sebelum Anda dapat mengatur gtid_mode=ON.

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

Jika GTID diaktifkan pada server sumber (gtid_mode = AKTIF), replika yang baru dibuat juga 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

Skenario Batasan/Pertimbangan
Replika pada server di Tingkat Harga yang Dapat Melonjak Tidak didukung
Harga Biaya menjalankan server replika didasarkan pada wilayah tempat server replika dijalankan
Pengaktifan ulang server sumber Jika Anda membuat replika untuk sumber yang tidak memiliki replika, sumber akan terlebih dahulu memulai ulang untuk mempersiapkan replikasi. Pertimbangkan hal ini dan lakukan operasi ini selama periode waktu di luar jam sibuk
Replika baru Replika baca dibuat sebagai instans Azure Database for MySQL Flexible Server 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 komputasi juga dapat diubah secara independen.

PENTING - Sebelum konfigurasi server sumber diperbarui 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 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:
- innodb_file_per_table
- log_bin_trust_function_creators
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.
Parameter tingkat sesi Saat mengonfigurasi parameter tingkat sesi seperti 'foreign_keys_checks' pada replika baca, pastikan nilai parameter yang diatur pada replika baca konsisten dengan server sumber.
Menambahkan kolom Kunci Primer AUTO_INCREMENT ke tabel yang ada di server sumber. Kami tidak merekomendasikan mengubah tabel dengan AUTO_INCREMENT pasca pembuatan replika baca, karena merusak replikasi. Tetapi jika Anda ingin menambahkan posting kolom peningkatan otomatis yang membuat server replika, kami sarankan kedua pendekatan ini:
- Buat tabel baru dengan skema tabel yang sama dengan yang ingin Anda ubah. Dalam tabel baru, ubah kolom dengan AUTO_INCREMENT lalu dari tabel asli pulihkan data. Letakkan tabel lama dan ganti namanya di sumbernya, ini tidak perlu kita hapus server replika tetapi mungkin perlu biaya penyisipan besar untuk membuat tabel cadangan.
- Metode lebih cepat lainnya adalah membuat ulang replika setelah menambahkan semua kolom penahapan otomatis.
Lainnya - Membuat replika replika tidak didukung.
- Tabel dalam memori dapat menyebabkan replika menjadi tidak sinkron. Hal ini merupakan batasan dari teknologi replikasi MySQL. Baca selengkapnya di dokumentasi referensi MySQL untuk informasi selengkapnya.
- Pastikan tabel server sumber memiliki kunci utama. Kurangnya kunci utama dapat mengakibatkan latensi replikasi antara sumber dan replika.
- Tinjau daftar lengkap batasan replikasi MySQL di dokumentasi MySQL

Langkah berikutnya