Tentang pemulihan dari bencana (DR) di Cloud SQL

MySQL   |  PostgreSQL   |  SQL Server

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.

Dua tutorial dikaitkan dengan dokumen DR ini:

• Pemulihan dari bencana (disaster recovery) Cloud SQL untuk MySQL: Proses failover dan penggantian yang lengkap
• Pemulihan dari bencana (disaster recovery) Cloud SQL untuk PostgreSQL: Proses failover dan penggantian yang lengkap

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:

1. Region utama (R1), yang menjalankan instance utama, menjadi tidak tersedia.
2. Tim operasi mengenali dan secara resmi mengonfirmasi bencana, dan memutuskan apakah failover diperlukan.
3. Jika failover diperlukan, Anda dapat mempromosikan replika baca lintas region di region sekunder (R2) untuk menjadi instance utama baru.
4. 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:

1. Region utama (R1), yang menjalankan database utama, menjadi tidak tersedia.
2. Tim operasi mengenali dan secara resmi mengonfirmasi bencana, dan memutuskan apakah failover diperlukan.
3. Jika failover diperlukan, Anda dapat mempromosikan replika baca lintas region di region sekunder (R2) menjadi instance utama baru.
4. Koneksi klien dikonfigurasi ulang untuk mengakses dan memproses pada instance primer (R2) yang baru.
5. 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.
6. 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.

Catatan: Anda dapat mengurangi RTO untuk proses DR lengkap dengan menghilangkan langkah 5 dan 6. Untuk melakukannya, buat replika lintas region di region sekunder (R2) sebagai replika dengan ketersediaan tinggi (HA) dan replika lintas-region di region ketiga (R3) sebagai replika bertingkat dengan sumbernya sebagai replika di R2.

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:

1. Promosikan replika lintas region yang baru dibuat di region utama asli (R1).
2. 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.
3. Konfigurasi ulang aplikasi Anda untuk terhubung ke instance utama yang baru.
4. Buat replika lintas region untuk instance utama baru di region DR (R2).
5. (Opsional) Agar tidak menjalankan beberapa instance utama independen, bersihkan instance utama di region DR (R2).

Pemulihan dari bencana (disaster recovery/DR) lanjutan

Pratinjau

Fitur ini tunduk pada "Persyaratan Penawaran Pra-GA" di bagian Persyaratan Layanan Umum dalam Persyaratan Khusus Layanan. Fitur pra-GA tersedia "sebagaimana adanya" dan mungkin memiliki dukungan terbatas. Untuk mengetahui informasi selengkapnya, lihat deskripsi tahap peluncuran.

Jika menggunakan edisi Cloud SQL Enterprise Plus, Anda dapat memanfaatkan DR lanjutan. DR lanjutan menyederhanakan pemulihan dan penggantian setelah failover lintas regional. Seperti yang dijelaskan dalam Proses pemulihan dari bencana, saat melakukan DR, Anda akan menghapus koneksi antara region yang gagal pada instance utama yang lama dan region operasional dari instance utama yang baru. Dengan DR, untuk memulihkan koneksi ke region deployment asli dan mendapatkan kembali instance utama lama, Anda harus melakukan serangkaian langkah penggantian manual.

Dengan DR lanjutan, saat terjadi kegagalan regional, Anda dapat memanggil failover replika. Dengan failover replika, Anda mempromosikan replika baca lintas region yang mirip dengan menjalankan DR reguler, hanya saja Anda mempromosikan replika pemulihan bencana yang ditetapkan (DR). Promosi replika DR dapat langsung diterapkan. Daripada menghapus instance utama yang lama, instance tersebut tetap menjadi bagian dari topologi replikasi asinkron Cloud SQL. Instance utama yang lama (instance A) pada akhirnya menjadi replika replika DR-nya (instance B) setelah replika DR dipromosikan ke instance utama yang baru.

Setelah instance utama yang lama (A) diubah menjadi replika, Anda dapat melakukan langkah terakhir DR lanjutan. Anda dapat mengembalikan deployment Cloud SQL ke status aslinya dan memulihkan instance primer lama (A) ke peran sebelumnya sebagai instance utama tanpa kehilangan data. Untuk melakukan pemulihan tanpa kehilangan data pada instance utama yang lama (A), Anda dapat menggunakan operasi switchover. Saat Anda melakukan peralihan, tidak ada data yang hilang karena instance utama (B) tetap berada dalam mode hanya baca hingga replika DR yang ditetapkan (A) mengejar instance utama (B). Setelah replika DR (A) menerima semua update replikasinya, replika DR (A) akan mengambil peran instance utama, sedangkan instance utama sebelumnya (B) otomatis dikonfigurasi ulang sebagai replika DR dari instance utama saat ini (A). Instance ditampilkan ke peran aslinya sehingga menampilkan topologi ke status aslinya sebelum DR dan failover replika.

Melalui DR lanjutan, semua instance yang terlibat dalam operasi failover dan switchover replika akan mempertahankan alamat IP-nya.

Catatan: Meskipun peralihan ini mengakibatkan nol kehilangan data, failover replika dapat mengakibatkan kehilangan data jika replika DR mengalami keterlambatan replikasi saat Anda memulai operasi failover replika.

Anda juga dapat menggunakan operasi pengalihan DR lanjutan untuk melakukan penelusuran DR rutin guna menguji dan menyiapkan topologi Cloud SQL untuk failover lintas regional sebelum terjadi bencana. Jika terjadi bencana yang sebenarnya, Anda dapat melakukan failover replika lintas regional yang telah diuji.

Replikasi pemulihan bencana (DR) yang ditetapkan

Sebagai komponen wajib dari DR lanjutan, replika DR memiliki karakteristik berikut:

• Replika DR adalah replika baca lintas region yang terhubung langsung.
• Anda dapat mengubah penetapan replika DR beberapa kali.
• Anda dapat mengubah penetapan replika DR kapan saja, kecuali selama operasi failover atau replikasi replika.

Selain itu, untuk mengurangi RTO setelah menggunakan DR lanjutan, sebaiknya lakukan hal berikut:

• Konfigurasikan replika DR dengan ukuran yang sama dengan instance utama.
• jika instance utama mengaktifkan HA, aktifkan juga HA di replika DR.

Failover replika

Failover replika terdiri dari langkah-langkah berikut:

1. Sebelum melakukan failover replika, Anda telah menetapkan replika DR ke instance utama dan mungkin telah menguji proses dengan melakukan peralihan.
2. Region utama, yang menjalankan database utama, menjadi tidak tersedia.
3. Tim operasi memutuskan bahwa diperlukan pemulihan dari bencana (disaster recovery).
4. Anda melakukan failover replika ke replika DR yang ditetapkan.
5. Replika DR lintas region yang ditetapkan akan langsung menjadi instance utama dan mulai menerima operasi baca dan tulis yang masuk.
6. Saat ini, Anda harus mengonfigurasi aplikasi agar mengarah ke instance utama yang baru.
7. Saat instance utama yang lama tersedia lagi, instance utama yang lama akan menjadi replika baca dari instance utama yang baru. Instance utama yang lama mempertahankan alamat IP-nya.

Setelah melakukan failover replika, Anda dapat memulihkan instance utama di region asli dengan melakukan operasi pengalihan, yang membalikkan pasangan instance utama dan replika DR yang sama.

Peralihan

Peralihan terdiri dari langkah-langkah berikut:

1. Sebelum memulai operasi switchover, Anda harus menetapkan replika DR ke instance utama.
2. Pastikan instance utama responsif. Anda hanya dapat melakukan peralihan saat instance utama dan replika DR sedang online.
3. Anda memulai proses {i>switchover<i}. Saat Anda memulai pengalihan, instance utama berhenti menerima operasi tulis dan menjadi hanya baca.
4. Tunggu hingga log biner disalin ke Cloud Storage.
5. Replika DR yang ditetapkan mengejar instance utama.
6. Jika jeda replikasi mencapai nol, replika DR dipromosikan sebagai instance utama baru. Instance utama yang baru mulai menerima koneksi masuk, termasuk pembacaan dan penulisan aplikasi.
7. Instance utama yang lama dikonfigurasi ulang sebagai replika baca.
8. Saat ini, Anda harus mengonfigurasi aplikasi agar mengarah ke instance utama yang baru.
9. PITR diaktifkan secara otomatis untuk instance utama yang baru. PITR hanya dapat dilakukan setelah pencadangan otomatis pertama.

Langkah selanjutnya

• Gunakan pemulihan dari bencana (DR) lanjutan.
• Cobalah tutorial pemulihan bencana (disaster recovery) Cloud SQL untuk MySQL.

• Jelajahi arsitektur referensi, diagram, dan praktik terbaik tentang Google Cloud. Lihat Cloud Architecture Center kami.