Halaman ini menjelaskan cara menggunakan dan mempromosikan replika baca lintas region (replika yang dibuat di region yang berbeda dengan region utama) untuk migrasi regional atau pemulihan dari bencana.
Ringkasan
Ada dua skenario umum untuk mempromosikan replika lintas-region:
- Migrasi regional: Lakukan migrasi terencana database ke region yang berbeda.
- Pemulihan dari bencana (disaster recovery): Gagal melalui database ke region lain jika region utama tidak tersedia.
Kedua kasus penggunaan melibatkan penyiapan replikasi lintas-region lalu mempromosikan replika tersebut. Perbedaan utama di antara keduanya adalah apakah promosi replika tersebut direncanakan (dalam kasus migrasi regional) atau tidak direncanakan (failover ke region replika diperlukan untuk melanjutkan operasi karena region utama telah menjadi tidak tersedia).
Migrasi regional
Anda dapat menggunakan replika lintas-region untuk memigrasikan database ke region lain dengan periode nonaktif minimal. Ide umumnya adalah membuat replika di region lain, menunggu hingga replikasi berhasil, mempromosikannya, lalu mengarahkan klien ke instance yang baru dipromosikan.
Langkah-langkah yang terlibat dalam promosi sama seperti langkah mempromosikan replika dalam wilayah; ikuti petunjuk tersebut untuk memastikan bahwa instance yang baru dipromosikan memiliki semua transaksi yang di-commit ke instance utama asli. Setelah Anda mempromosikan replika dan memastikan bahwa instance yang baru dipromosikan berfungsi, update semua klien database agar terhubung ke instance baru.
Pemulihan dari bencana (disaster recovery/DR)
Replika lintas-region dapat digunakan sebagai bagian dari prosedur pemulihan dari bencana. Anda dapat mempromosikan replika lintas region untuk melakukan failover ke region lain jika region instance utama tidak tersedia untuk jangka waktu yang lama.
Untuk informasi lebih lanjut tentang pemulihan dari bencana (disaster recovery), lihat Tentang pemulihan dari bencana (disaster recovery) di Cloud SQL.
Pemulihan dari bencana (disaster recovery/DR) lanjutan
Jika menggunakan edisi Cloud SQL Enterprise Plus, Anda dapat menetapkan replika baca lintas region sebagai replika pemulihan dari bencana (replika DR) untuk pemulihan bencana (DR) lanjutan. Dengan DR lanjutan, Anda melakukan failover replika untuk mengganti instance utama dengan replika DR yang ditetapkan. Instance utama lama akhirnya menjadi replika replika DR yang dipromosikan. Anda hanya dapat melakukan failover replika ke replika DR yang ditentukan. Anda masih dapat mempromosikan replika baca lainnya tanpa failover.
Untuk mengembalikan deployment ke status asli setelah failover replika dengan nol kehilangan data, Anda dapat melakukan pengalihan. Karena instance utama yang lama adalah replika instance utama baru, Anda dapat beralih peran lagi untuk memulihkan instance utama yang lama.
Untuk informasi selengkapnya, lihat Pemulihan dari bencana (DR) lanjutan. DR Lanjutan berada dalam Pratinjau.
Memverifikasi kriteria failover
Karena replikasi bersifat asinkron, saat terjadi pemadaman layanan regional dan upaya failover dicoba, beberapa transaksi terbaru yang di-commit ke replika utama mungkin akan hilang (tidak direplikasi ke replika). Setiap kali instance utama tidak tersedia, langkah-langkah berikut akan menunjukkan (1) cara menentukan jumlah data, jika ada, yang mungkin hilang dalam failover lintas-region dan (2) bagaimana cara untuk memastikan bahwa replika yang dipromosikan mencerminkan sebanyak mungkin penulisan terbaru.
Pertama, periksa nilai Replication Lag untuk instance replika di
dasbor pemantauan, yang menunjukkan seberapa jauh replika tersebut berada
di belakang replika utama dalam hitungan detik. Nilai metrik ini pada saat sebelum replika
utama menjadi tidak tersedia, menunjukkan jangka waktu
dimana transaksi yang di-commit ke replika utama mungkin telah hilang. Misalnya, jika
Replication Lag menampilkan 5 detik, replika mungkin tidak memiliki
operasi tulis ke replika utama dari 5 detik sebelum replika utama menjadi tidak tersedia.
(Jumlah data yang hilang sebenarnya mungkin lebih kecil dari ini karena Replication
Lag juga menyertakan transaksi yang berhasil diterima
oleh replika tetapi belum diterapkan.)
Kemudian, hubungkan ke instance replika dengan klien MySQL dengan mengikuti petunjuk di
halaman status replikasi (lihat tab mysql Client). Lihat petunjuk yang berkaitan dengan metrik
Master_Log_File, Read_Master_Log_Pos,
Relay_Master_Log_File, dan
Exec_Master_Log_Pos. Pastikan replika telah memproses semua transaksi yang telah
diterima dari replika utama. Hal ini memastikan bahwa saat dipromosikan, replika mencerminkan
semua transaksi yang diterima sebelum transaksi utama menjadi tidak tersedia.
Mempromosikan replika baca
Setelah menentukan bahwa kriteria failover terpenuhi, Anda dapat mempromosikan salah satu replika ke instance mandiri yang dapat ditulis. Pertimbangkan skenario berikut:
- Region A (us-central1) memiliki instance utama Ketersediaan Tinggi (db-a-0)
- Region B (us-west1) memiliki replika lintas region dengan Ketersediaan Tinggi (db-b-1) sebesar db-a-0
- Region C (us-east1) memiliki replika lintas region (db-c-1) dari db-a-0
Anda dapat memilih untuk mempromosikan db-b-1 di Wilayah B untuk menjadi instance mandiri yang dapat ditulis.
Lihat Mempromosikan replika untuk petunjuk mendetail.
Pastikan jenis mesin sesuai
Pastikan jenis mesin dari instance yang baru dipromosikan sesuai dengan beban kerjanya dengan memantau metrik pada instance seperti penggunaan CPU dan memori. Jika instance yang baru dipromosikan lebih kecil dari instance utama sebelumnya, sebaiknya ubah ukuran instance yang dipromosikan agar cocok dengan instance utama sebelumnya sehingga dapat menangani jumlah beban yang sama.
Mengaktifkan ketersediaan tinggi untuk instance yang dipromosikan
Untuk konfigurasi pemulihan dari bencana, sebaiknya konfigurasikan replika yang ingin Anda promosikan sebagai replika dengan ketersediaan tinggi. Atau, konfigurasikan instance yang baru dipromosikan sebagai ketersediaan tinggi. Jika memilih untuk tidak mengonfigurasi replika baca dengan ketersediaan tinggi, Anda juga dapat mengonfigurasi instance dengan ketersediaan tinggi jika dan saat Anda mempromosikannya.
Saat dipromosikan, replika baca secara otomatis dikonfigurasi dengan cadangan. Mengonfigurasi replika baca untuk ketersediaan tinggi dilakukan dengan cara yang sama seperti untuk instance utama. Untuk mengetahui informasi selengkapnya, baca mengonfigurasi instance untuk ketersediaan tinggi.
Membuat ulang replika tambahan
Jika Anda mempromosikan replika untuk menjadi instance utama, Anda perlu membuat ulang replika lainnya dari instance utama sebelumnya. Misalnya, pertimbangkan konfigurasi yang direferensikan sebelumnya dan diulang di sini:
- Region A (us-central1) memiliki instance utama Ketersediaan Tinggi (db-a-0)
- Region B (us-west1) memiliki replika lintas region (db-b-1) db-a-0
- Region C (us-east1) memiliki replika lintas region (db-c-1) dari db-a-0
Jika instance utama (db-a-0) tidak tersedia, Anda dapat mempromosikan replika di region B untuk menjadi yang utama. Untuk memiliki replika tambahan di region A dan C lagi, hapus instance lama (instance utama sebelumnya di A, dan replika di C), dan buat replika baca baru dari instance utama baru di B.
Konfigurasi yang dihasilkan adalah:
- Region A (us-central1) kini memiliki replika lintas region (db-a-1)
- Region B (us-west1) sekarang memiliki instance utama (db-b-1)
- Region C (us-east1) kini memiliki replika lintas region baru (db-c-2)