Tentang pemulihan dari bencana (DR) di Cloud SQL

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 adalah layanan regional (jika Cloud SQL dikonfigurasi untuk ketersediaan tinggi (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 yang 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 Cloud SQL Service Level Agreement (99,99% ketersediaan, 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):

Instance utama dan standby terletak di satu region dan replika baca berada di region kedua.

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. Akibatnya, saat terjadi failover, RPO replika baca lintas region kemungkinan bukan nol.

Proses pemulihan dari bencana (DR)

Proses pemulihan dari bencana (DR) dimulai saat region utama menjadi tidak tersedia. Untuk melanjutkan pemrosesan di region sekunder, Anda memicu failover instance utama dengan mempromosikan replika baca lintas region. Proses DR menetapkan langkah-langkah operasional yang harus dilakukan, baik secara manual maupun otomatis, untuk mengurangi kegagalan regional dan menetapkan instance utama yang berjalan di region sekunder.

Diagram berikut menunjukkan proses DR:

Jika region 1 tidak tersedia, replika baca asli akan dipromosikan menjadi yang utama.

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) 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 database 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:

Klien mulai mengakses instance utama baru dan replika baca disiapkan di region ketiga.

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.

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.

Melakukan penggantian ke region utama asli

Seperti yang diuraikan sebelumnya, dokumen ini menyediakan langkah-langkah untuk melakukan penggantian 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. Konfigurasi ulang aplikasi Anda untuk terhubung ke instance utama yang baru.
  3. Buat replika lintas-region untuk instance utama baru di region DR (R2).
  4. (Opsional) Untuk menghindari menjalankan beberapa instance utama independen, bersihkan instance utama di region DR (R2).

Replika yang dapat disusun bertingkat

Cloud SQL memungkinkan Anda membuat replika untuk skenario pengujian dan pemulihan bencana lintas region. Anda dapat membuat replika dengan tanda cascadable-replica di region yang berbeda dari instance utama. Jika terjadi bencana di region instance utama, Anda akan memulai failover ke replika yang dapat disusun bertingkat. Setelah instance utama asli kembali online dan berfungsi sebagai replika yang berfungsi, Anda dapat menggunakan operasi pengalihan untuk beralih kembali ke instance utama asli.

Replika yang dapat disusun bertingkat memiliki dua kemampuan tambahan yang tidak dimiliki replika baca lainnya:

  • Anda dapat melampirkan replika baca tambahan (replika bertingkat) ke replika baca yang dapat disusun bertingkat. Cloud SQL mengirim traffic replikasi lintas region ke replika yang dapat disusun bertingkat hanya sekali, lalu replika yang dapat disusun bertingkat meneruskan traffic ke replika dalam region-nya. Arsitektur ini dapat menghemat biaya transfer data jaringan antar-region saat Anda perlu memiliki beberapa replika di region lain.
  • Anda dapat menggunakan replika baca yang dapat disusun bertingkat sebagai target untuk operasi pengalihan dan penggantian saat terjadi kegagalan dalam skenario pemulihan dari bencana lintas region. Operasi ini mengonfigurasi ulang replika yang dapat disusun bertingkat menjadi instance utama dalam cluster.

Anda dapat menguji disaster recovery dengan salah satu dari dua cara berikut:

  • Promosi replika Anda
  • Pemulihan dari bencana lanjutan

Pemulihan dari bencana (DR) lanjutan

Jika menggunakan edisi Cloud SQL Enterprise Plus, Anda dapat memanfaatkan DR lanjutan. DR lanjutan menyederhanakan pemulihan dan penggantian setelah terjadi failover lintas region. Seperti yang dijelaskan dalam Proses disaster recovery, saat melakukan DR, Anda akan menghapus koneksi antara region yang gagal dari instance utama lama dan region operasional dari instance utama 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 melakukan DR reguler, kecuali Anda mempromosikan replika pemulihan dari bencana (DR) yang ditetapkan. Untuk Cloud SQL untuk SQL Server, Anda membuat replika DR dengan membuat replika lintas region dari instance utama dengan flag cascadable-replica. Promosi replika DR akan langsung dilakukan. Selain itu, saat Anda membuat instance utama baru atau menetapkan replika DR untuk instance utama yang ada, Cloud SQL akan membuat endpoint tulis. Endpoint tulis adalah nama DNS yang di-resolve ke alamat IP instance utama. Saat replika DR dipromosikan, endpoint tulis akan diperbarui untuk mengarah ke instance utama yang baru dipromosikan. Hal ini memastikan bahwa setiap aplikasi yang mencoba terhubung menggunakan endpoint tulis akan dialihkan ke instance yang dipromosikan.

Alih-alih menghapus instance utama lama, instance tersebut tetap menjadi bagian dari topologi replikasi asinkron Cloud SQL. Instance utama lama (instance A) pada akhirnya menjadi replika replika DR-nya (instance B) setelah replika DR dipromosikan ke instance utama baru.

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

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

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

Replika pemulihan dari bencana (DR)

Sebagai komponen yang diperlukan untuk 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.
  • Replika DR adalah replika yang dapat disusun secara bertingkat, yang Anda buat dengan flag cascadable-replica. Agar dapat berfungsi sebagai replika DR, replika yang dapat disusun bertingkat harus berada di region yang terpisah dari instance utama.
  • Anda tidak dapat memiliki lebih dari satu replika DR di suatu region.
  • Anda dapat mengubah penetapan replika DR kapan saja, kecuali selama operasi switchover atau failover 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 telah mengaktifkan HA, sebaiknya Anda juga mengaktifkan HA di replika DR. Untuk melakukannya, verifikasi terlebih dahulu apakah primary telah mengaktifkan HA. Kemudian, lakukan pengalihan ke replika DR. Setelah operasi pengalihan selesai, aktifkan HA di instance utama baru. Kemudian, Anda dapat beralih kembali ke instance utama lama. Replika DR mempertahankan konfigurasi HA-nya bahkan setelah menjadi replika lagi.

Failover replika

Untuk meringkas, failover replika terdiri dari peristiwa berikut:

  1. Anda membuat dan menetapkan replika DR.
  2. Region utama menjadi tidak tersedia.
  3. Anda melakukan failover replika ke replika DR.
  4. Endpoint tulis diperbarui dan mulai mengarah ke instance utama baru.
  5. Saat instance utama asli kembali online, instance tersebut akan menjadi replika baca dari instance utama baru.
  6. Anda dapat menggunakan operasi pengalihan untuk memulihkan deployment ke topologi aslinya.

Untuk melihat detail dan diagram operasi failover replika, klik tab berikut.

Menetapkan replika DR

Sebelum melakukan failover replika, Anda telah menetapkan replika DR ke instance utama dan mungkin telah menguji prosesnya dengan melakukan pengalihan.

Arsitektur instance Cloud SQL dalam konfigurasi aslinya dari dua region yang berbeda dengan kedua region tersebut dalam kondisi baik.
Gambar 1: Semua region dalam kondisi baik

Terjadi pemadaman

Region utama, yang menjalankan database utama, menjadi tidak tersedia.

Arsitektur instance Cloud SQL dalam konfigurasi saat satu region mengalami pemadaman layanan.
Gambar 2: Region R1 mengalami pemadaman layanan

Failover replika

Setelah menentukan bahwa pemulihan dari bencana diperlukan, Anda melakukan failover replika ke replika DR.

Replika DR langsung menjadi instance utama dan mulai menerima operasi baca dan tulis masuk. Endpoint tulis diperbarui dan mulai mengarah ke instance utama baru.

Arsitektur instance Cloud SQL tempat endpoint tulis DNS diperbarui untuk mengarah ke instance utama baru di region yang sehat.
Gambar 3: Melakukan failover replika untuk mengakhiri pemadaman

Utama asli menjadi replika

Setelah replika dipromosikan, Cloud SQL akan memeriksa secara berkala apakah instance utama asli sudah kembali online. Jika instance utama asli online, Cloud SQL akan membuat ulang instance utama lama sebagai replika instance yang dipromosikan. Instance utama lama mempertahankan alamat IP-nya.

Jika instance utama lama tidak aktif selama 24 jam, Cloud SQL akan menghapusnya dari topologi replikasi untuk memastikan log transaksi di instance utama baru dan replika lainnya tidak tumbuh tanpa batas.

Arsitektur instance Cloud SQL tempat instance utama asli menjadi replika dari replika DR.
Gambar 4: Instance utama asli menjadi replika DR

Failback ke versi asli

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.

Arsitektur instance Cloud SQL tempat instance utama asli menjadi replika dari replika DR.
Gambar 5: Failback menggunakan pengalihan ke deployment asli

Beralih

Untuk meringkas, operasi pengalihan terdiri dari peristiwa berikut:

  1. Anda membuat dan menetapkan replika DR.
  2. Anda memulai pengalihan.
  3. Saat jeda replikasi turun menjadi nol, instance utama baru akan mulai menerima koneksi masuk.
  4. Instance utama lama menjadi replika baca.
  5. Jika endpoint tulis DNS sedang digunakan, endpoint tulis DNS akan diperbarui agar mengarah ke instance utama baru.

Untuk melihat detail dan diagram operasi pengalihan, klik tab berikut.

Menetapkan replika DR

Sebelum memulai operasi *switchover*, Anda harus menetapkan replika DR ke instance utama.

Pastikan instance utama responsif. Anda hanya dapat melakukan alih-alih saat instance utama dan replika DR online.

Arsitektur instance Cloud SQL dalam konfigurasi aslinya dari dua region yang berbeda dengan kedua region tersebut dalam kondisi baik.
Gambar 1: Deployment asli

Memulai pengalihan

Anda memulai pengalihan. Saat Anda memulai pengalihan, replikasi ke replika DR akan beralih ke mode sinkron. Replika DR akan mengejar instance utama dan mengubah statusnya menjadi disinkronkan. Saat jeda replikasi turun menjadi nol, replika DR akan dipromosikan sebagai instance utama baru. Instance utama baru mulai menerima koneksi masuk, termasuk operasi baca dan tulis aplikasi.

Arsitektur instance Cloud SQL tempat pengalihan dilakukan.
Gambar 2: Memulai pengalihan dan mempromosikan replika DR ke instance utama saat jeda replikasi = 0

Endpoint diperbarui

Setelah replika DR dipromosikan ke instance utama baru, endpoint tulis DNS diperbarui dan mulai mengarah ke instance utama baru.

Instance utama lama dikonfigurasi ulang sebagai replika baca.

Arsitektur instance Cloud SQL tempat pengalihan dilakukan dan endpoint tulis diperbarui.
Gambar 3: Penyelesaian pengalihan

Menulis endpoint

Endpoint tulis adalah nama layanan nama domain (DNS) yang di-resolve ke alamat IP instance utama. Endpoint ini mengalihkan koneksi masuk ke instance utama secara otomatis jika terjadi operasi failover replika atau switchover. Anda dapat menggunakan endpoint tulis dalam string koneksi SQL, bukan alamat IP. Dengan menggunakan endpoint tulis, Anda dapat menghindari perlunya melakukan perubahan koneksi aplikasi saat terjadi pemadaman layanan regional.

Endpoint tulis mengharuskan Cloud DNS API diaktifkan di project tempat Anda membuat atau memiliki instance utama edisi Cloud SQL Enterprise Plus yang ada. Saat Anda membuat instance edisi Cloud SQL Enterprise Plus dengan alamat IP pribadi dan jaringan yang diotorisasi, Cloud SQL akan otomatis membuat endpoint tulis untuk instance tersebut. Jika Anda sudah memiliki instance utama edisi Cloud SQL Enterprise Plus, Cloud SQL akan membuat endpoint tulis saat Anda membuat replika DR (replika lintas region yang Anda buat dengan tanda cascadable-replica ). Jika instance utama berubah karena operasi pengalihan atau penggantian replika, Cloud SQL akan menetapkan endpoint tulis ke replika DR saat replika DR menjadi instance utama yang baru.

Untuk informasi selengkapnya tentang cara mendapatkan endpoint tulis untuk instance, lihat Melihat informasi instance. Untuk mengetahui informasi selengkapnya tentang cara menggunakan endpoint tulis untuk terhubung ke instance, lihat Menghubungkan menggunakan endpoint tulis.

Langkah selanjutnya