Halaman ini memperkenalkan pemulihan dari bencana (disaster recovery) di Cloud SQL.
Ringkasan
Di Google Cloud, pemulihan dari bencana database (DR) berfokus pada penyediaan keberlangsungan pemrosesan, khususnya saat region gagal atau tidak tersedia. Cloud SQL alah layanan regional (jika Cloud SQL dikonfigurasi untuk HA). Oleh karena itu, jika region Google Cloud yang menghosting database Cloud SQL menjadi tidak tersedia, database Cloud SQL juga tidak akan tersedia.
Untuk melanjutkan pemrosesan, Anda harus menyediakan database di region sekunder sesegera mungkin. Paket DR ini mengharuskan Anda mengonfigurasi replika baca lintas region di Cloud SQL. Failover berdasarkan ekspor/impor atau pencadangan/pemulihan juga dapat dilakukan, tetapi pendekatan tersebut memerlukan waktu lebih lama, terutama untuk database yang besar.
Skenario bisnis berikut adalah contoh yang menjamin konfigurasi failover lintas region:
- Perjanjian tingkat layanan aplikasi bisnis lebih besar daripada Perjanjian Tingkat Layanan Cloud SQL regional (ketersediaan 99,99%, bergantung pada edisi Cloud SQL Anda). Dengan melakukan failover ke region lain, Anda dapat memitigasi pemadaman layanan.
- Semua tingkat aplikasi bisnis sudah multi-regional dan dapat terus memproses saat terjadi pemadaman layanan region. Konfigurasi failover lintas region memastikan ketersediaan database yang berkelanjutan.
- Batas waktu pemulihan (RTO) dan tujuan titik pemulihan (RPO) yang diperlukan adalah dalam menit, bukan dalam jam. Melakukan failover ke region lain lebih cepat daripada membuat ulang database.
Secara umum, ada dua varian untuk proses DR:
- Database gagal terhubung ke region sekunder. Setelah siap dan digunakan oleh aplikasi, database tersebut akan menjadi database utama baru dan tetap menjadi database utama.
- Database akan gagal terhubung ke region sekunder, tetapi kembali ke region utama setelah region utama pulih dari kegagalannya.
Ringkasan pemulihan dari bencana (disaster recovery) database Google Cloud SQL ini menjelaskan varian kedua, yaitu saat database yang gagal dipulihkan dan kembali ke region utama. Varian proses DR ini sangat relevan untuk database yang harus berjalan di region utama karena latensi jaringan, atau karena beberapa resource hanya tersedia di region utama. Dengan varian ini, database berjalan di region sekunder hanya selama pemadaman layanan di region utama.
Arsitektur pemulihan dari bencana (disaster recovery)
Diagram berikut menunjukkan arsitektur minimal yang mendukung DR database untuk instance Cloud SQL dengan ketersediaan tinggi (HA):
Arsitekturnya berfungsi sebagai berikut:
- Dua instance Cloud SQL (instance utama dan instance standby) terletak di dua zona terpisah dalam satu region (region utama). Instance disinkronkan menggunakan persistent disk regional.
- Satu instance Cloud SQL (replika baca lintas region) terletak di region kedua (region sekunder). Untuk DR, replika baca lintas region disiapkan untuk menyinkronkan (dengan menggunakan replikasi asinkron) dengan instance utama menggunakan penyiapan replika baca.
Instance utama dan standby menggunakan disk regional yang sama, sehingga statusnya identik.
Karena penyiapan ini menggunakan replikasi asinkron, ada kemungkinan replika baca lintas region tertinggal dari instance utama. Saat failover terjadi, replika baca lintas region mungkin mendukung RPO nol.
Proses pemulihan dari bencana (disaster recovery/DR)
Proses pemulihan dari bencana (DR) dimulai saat region utama tidak lagi tersedia. Untuk melanjutkan pemrosesan di region sekunder, Anda dapat memicu failover instance utama dengan mempromosikan replika baca lintas region. Proses DR menentukan langkah-langkah operasional yang harus dilakukan, baik secara manual maupun otomatis, untuk memitigasi kegagalan regional dan menetapkan instance utama yang berjalan di region sekunder.
Diagram berikut menunjukkan proses DR:
Proses DR terdiri dari langkah-langkah berikut:
- Region utama (R1), yang menjalankan instance utama, menjadi tidak tersedia.
- Tim operasi mengenali dan secara resmi mengonfirmasi bencana, dan memutuskan apakah failover diperlukan.
- Jika failover diperlukan, Anda dapat mempromosikan replika baca lintas region di region sekunder (R2) untuk menjadi instance utama baru.
- Koneksi klien dikonfigurasi ulang untuk melanjutkan pemrosesan pada instance utama yang baru dan mengakses instance utama di R2.
Proses awal ini menetapkan kembali {i>database<i} utama yang berfungsi. Namun, tindakan ini tidak membuat arsitektur DR yang lengkap, di mana instance utama yang baru itu sendiri memiliki instance standby dan replika baca lintas region.
Proses DR yang lengkap memastikan bahwa satu instance, yaitu instance utama yang baru, diaktifkan untuk HA dan memiliki replika baca lintas region. Proses DR yang lengkap juga memberikan penggantian ke deployment asli di region utama asli.
Kegagalan merujuk ke region sekunder
Proses DR yang lengkap memperluas proses DR dasar dengan menambahkan langkah-langkah untuk membuat arsitektur DR lengkap setelah failover. Diagram berikut menunjukkan arsitektur DR database yang lengkap setelah failover:
Proses DR database yang lengkap terdiri dari langkah-langkah berikut:
- Region utama (R1), yang menjalankan database utama, menjadi tidak tersedia.
- Tim operasi mengenali dan secara resmi mengonfirmasi bencana, dan memutuskan apakah failover diperlukan.
- Jika failover diperlukan, Anda dapat mempromosikan replika baca lintas region di region sekunder (R2) menjadi instance utama baru.
- Koneksi klien dikonfigurasi ulang untuk mengakses dan memproses pada instance primer (R2) yang baru.
- Instance standby baru dibuat dan dimulai di R2 dan ditambahkan ke instance utama. Instance standby berada di zona yang berbeda dengan instance utama. Instance utama kini sangat tersedia karena instance standby telah dibuat untuknya.
- Di region ketiga (R3), replika baca lintas-region baru dibuat dan dilampirkan ke instance utama. Pada tahap ini, arsitektur pemulihan dari bencana yang lengkap dibuat ulang dan dapat dioperasikan.
Jika region utama asli (R1) tersedia sebelum langkah 6 diimplementasikan, replika baca lintas region dapat langsung ditempatkan di region R1, bukan region R3. Dalam hal ini, penggantian ke region utama asli (R1) tidak terlalu kompleks dan memerlukan lebih sedikit langkah.
Menghindari kondisi split-brain
Kegagalan region utama (R1) tidak berarti bahwa instance utama yang asli dan instance standby-nya otomatis dimatikan, dihapus, atau dibuat tidak dapat diakses saat R1 tersedia kembali. Jika R1 tersedia, klien dapat membaca dan menulis data (bahkan secara tidak sengaja) pada instance utama asli. Dalam hal ini, situasi split-brain apat berkembang, yaitu beberapa klien mengakses data lama di database utama yang lama, dan klien lainnya mengakses data baru di database utama yang baru, yang mengakibatkan masalah dalam bisnis Anda.
Untuk menghindari situasi split-brain, Anda harus memastikan bahwa klien tidak dapat lagi mengakses instance utama asli setelah R1 tersedia. Idealnya, Anda harus membuat instance utama yang asli tidak dapat diakses sebelum klien mulai menggunakan instance primer yang baru, lalu menghapus instance utama yang asli tepat setelah Anda membuatnya tidak dapat diakses.
Membuat cadangan awal setelah failover
Saat Anda mempromosikan replika baca lintas region menjadi replika baca utama baru dalam failover, transaksi dalam replika baca utama yang baru mungkin tidak sepenuhnya disinkronkan dengan transaksi dari transaksi utama yang asli. Oleh karena itu, transaksi tersebut tidak tersedia di instance baru.
Sebagai praktik terbaik, sebaiknya segera cadangkan instance utama baru di awal failover dan sebelum klien mengakses database. Cadangan ini mewakili status yang konsisten dan diketahui pada titik failover. Cadangan tersebut dapat penting untuk tujuan peraturan atau untuk pemulihan ke status yang diketahui jika klien mengalami masalah saat mengakses status utama baru.
Mengembalikan ke wilayah utama aslinya
Seperti yang diuraikan sebelumnya, dokumen ini memberikan langkah-langkah untuk melakukan fallback ke region asli (R1). Ada dua versi berbeda dari proses penggantian.
- Jika membuat replika baca lintas region baru di region tersier (R3), Anda harus membuat replika baca lintas region (kedua) lainnya di region utama (R1).
- Jika membuat replika baca lintas-region baru di region utama (R1), Anda tidak perlu membuat replika baca lintas-region tambahan lainnya di R1.
Setelah replika baca lintas region di R1 ada, instance Cloud SQL dapat dikembalikan ke R1. Karena penggantian ini dipicu secara manual dan tidak didasarkan pada pemadaman, Anda dapat memilih hari dan waktu yang sesuai untuk aktivitas pemeliharaan ini.
Dengan demikian, untuk mencapai DR lengkap yang memiliki replika baca utama, standby, dan lintas region, Anda memerlukan dua failover. Failover pertama dipicu oleh penghentian (failover yang sebenarnya), dan failover kedua menetapkan kembali deployment awal (penggantian).
Penggantian ke region utama asli (R1) terdiri dari langkah-langkah berikut:
- Promosikan replika lintas region yang baru dibuat di region utama asli (R1).
- Jika instance yang dipromosikan awalnya tidak dibuat sebagai replika dengan ketersediaan tinggi (HA), aktifkan HA pada instance untuk mendapatkan perlindungan dari kegagalan di level zona.
- Konfigurasi ulang aplikasi Anda untuk terhubung ke instance utama yang baru.
- Buat replika lintas region untuk instance utama baru di region DR (R2).
- (Opsional) Agar tidak menjalankan beberapa instance utama independen, bersihkan instance utama di region DR (R2).
Langkah selanjutnya
- Pelajari arsitektur referensi, diagram, dan praktik terbaik tentang Google Cloud. Lihat Cloud Architecture Center kami.