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

---

Catatan: Dokumen atau bagian ini menyertakan referensi ke satu atau beberapa persyaratan yang Google anggap tidak sopan atau menyinggung. Istilah tersebut digunakan karena merupakan kata kunci dalam software yang dijelaskan dalam dokumen ini.

Tutorial ini menjelaskan proses failover dan penggantian pemulihan dari bencana (DR) lengkap di Cloud SQL untuk MySQL menggunakan replika baca lintas region.

Dalam tutorial ini, Anda akan menyiapkan instance Cloud SQL untuk MySQL untuk DR ketersediaan tinggi (HA) dan menyimulasikan pemadaman layanan. Kemudian, Anda akan menjalankan proses DR untuk memulihkan deployment awal setelah pemadaman layanan teratasi.

Penting: Tutorial ini hanya berlaku untuk pemulihan dari bencana (DR) umum, yang tersedia bagi semua instance Cloud SQL untuk MySQL. Jika menggunakan edisi Cloud SQL Enterprise Plus, Anda memiliki opsi untuk menggunakan pemulihan dari bencana (DR) lanjutan. Untuk informasi selengkapnya tentang DR lanjutan, lihat Pemulihan dari bencana (disaster recovery) lanjutan dan Menggunakan pemulihan dari bencana lanjutan (DR). DR Lanjutan ada di Pratinjau.

Tutorial ini ditujukan untuk arsitek, administrator, dan engineer database.

Untuk membaca ringkasan cara kerja pemulihan dari bencana SQL, lihat Tentang pemulihan dari bencana (disaster recovery) di Cloud SQL.

Tujuan

• Membuat instance Cloud SQL untuk MySQL dengan ketersediaan tinggi (HA).
• Men-deploy replika baca lintas region di Google Cloud menggunakan Cloud SQL untuk MySQL.
• Menyimulasikan bencana dan failover dengan Cloud SQL untuk MySQL.
• Pahami langkah-langkah untuk memulihkan deployment awal Anda menggunakan penggantian dengan Cloud SQL untuk MySQL.

Dokumen ini hanya berfokus pada proses penggantian dan failover DR lintas region. Untuk informasi tentang proses failover HA satu region, lihat Ringkasan konfigurasi ketersediaan tinggi.

Biaya

Dalam dokumen ini, Anda menggunakan komponen Google Cloud yang dapat ditagih berikut:

• Cloud SQL

Untuk membuat perkiraan biaya berdasarkan proyeksi penggunaan Anda, gunakan kalkulator harga. Pengguna baru Google Cloud mungkin memenuhi syarat untuk mendapatkan uji coba gratis.

Setelah menyelesaikan tugas yang dijelaskan dalam dokumen ini, Anda dapat menghindari penagihan berkelanjutan dengan menghapus resource yang Anda buat. Untuk mengetahui informasi selengkapnya, lihat Pembersihan.

Sebelum memulai

1. Di konsol Google Cloud, pada halaman pemilih project, pilih atau buat project Google Cloud.

   Catatan: Jika tidak berencana untuk menyimpan resource yang Anda buat dalam prosedur ini, buatlah project, bukan memilih project yang ada. Setelah menyelesaikan langkah ini, Anda dapat menghapus project, yang menghapus semua resource yang terkait dengan project ini.

   Buka pemilih project

2. Pastikan penagihan telah diaktifkan untuk project Google Cloud Anda.

3. Di konsol Google Cloud, aktifkan Cloud Shell.

   Aktifkan Cloud Shell

Tahap 1: Menyiapkan instance database HA untuk DR

Fase berikut (1-3) akan memandu Anda menyelesaikan proses failover dan penggantian. Anda dapat menjalankan semua perintah menggunakan perintah gcloud di Cloud Shell. Untuk menyederhanakan proses, tutorial ini menggunakan setelan default jika memungkinkan (misalnya, versi Cloud SQL default). Dalam lingkungan produksi, Anda dapat menambahkan konfigurasi lain.

Menetapkan variabel lingkungan

Bagian ini menyediakan contoh variabel lingkungan yang mendefinisikan berbagai nama dan region yang diperlukan untuk perintah yang Anda jalankan dalam tutorial ini. Anda dapat menyesuaikan contoh variabel ini sesuai kebutuhan Anda.

Tabel berikut menjelaskan nama instance, perannya, dan region deployment-nya untuk setiap fase DR dan proses penggantian dalam tutorial ini. Anda juga dapat memberikan nama dan wilayah Anda sendiri.

Fase awal
Nama instance	Peran	Region
instance-1	Instance utama	us-west1
instance-2	Standby	us-west1
instance-3	Replika baca lintas region	us-west2

Fase bencana
Nama instance	Peran	Region
instance-3	Instance utama	us-west2
instance-4	Standby	us-west2
instance-5	Replika baca lintas region	us-west3
instance-6	Replika baca lintas region	us-west1

Fase penggantian (final)
Nama instance	Peran	Region
instance-6	Instance utama	us-west1
instance-7	Standby	us-west1
instance-8	Replika baca lintas region	us-west2

Catatan: Anda tidak menggunakan nama instance-2, instance-4, dan instance-7 untuk membuat instance Cloud SQL. Instance tersebut akan dibuat secara otomatis saat mengaktifkan HA di instance-1, instance-3, dan instance-6. Alasan untuk memberikan nama tambahan ini adalah agar dapat merujuk ke instance HA yang dibuat secara otomatis dan memiliki skema penamaan konsisten yang sesuai dengan instance Cloud SQL sebenarnya yang sedang dibuat.

Nama instance dalam tabel sebelumnya tidak dienkode dengan perannya. Dalam situasi DR, fungsi instance dapat berubah—misalnya, replika mungkin menjadi yang utama. Jika nama instance utama baru berisi kata replica, dapat terjadi kebingungan dan konflik. Oleh karena itu, sebaiknya jangan mengenkode nama instance dengan fungsi atau peran yang dijalankannya.

Tabel sebelumnya mencantumkan nama instance standby. Meskipun tutorial ini tidak menjalankan failover dengan HA, tutorial ini menyertakan nama-nama instance standby agar lengkap.

Fase penggantian membuat kembali deployment asli dari fase awal di region asli yang sama. Namun, dalam penggantian, nama instance harus berubah karena nama aslinya tidak akan segera tersedia meskipun instance asli dihapus. Untuk mendukung pembuatan instance yang cepat di fase penggantian, Anda harus menggunakan nama instance yang tidak sama dengan nama yang digunakan pada fase awal.

• Di Cloud Shell, tetapkan variabel lingkungan berdasarkan spesifikasi pada tabel sebelumnya:

  export primary_name=instance-1
  export primary_tier=db-n1-standard-2
  export primary_region=us-west1
  export primary_root_password=my-root-password
  export primary_backup_start_time=22:00
  export cross_region_replica_name=instance-3
  export cross_region_replica_region=us-west2
  

  Jika Anda ingin menggunakan tingkat yang berbeda untuk instance utama, cantumkan tingkat yang tersedia untuk Anda, lalu tetapkan nilai yang berbeda ke primary_tier:

  gcloud sql tiers list
  

  Untuk mengetahui daftar region tempat Anda dapat men-deploy Cloud SQL, lihat Setelan instance.

Membuat instance database utama

1. Di Cloud Shell, buat satu instance Cloud SQL:

   gcloud sql instances create $primary_name \
       --tier=$primary_tier \
       --region=$primary_region
   

   Perintah gcloud dijeda hingga instance dibuat.

2. Atur kata sandi root:

   gcloud sql users set-password root \
       --host=% \
       --instance $primary_name \
       --password $primary_root_password
   

Membuat database utama

1. Di Cloud Shell, login ke shell MySQL dan masukkan sandi root pada perintah:

   gcloud sql connect $primary_name --user=root
   

2. Pada perintah MySQL, buat database dan upload data pengujian:

   CREATE DATABASE guestbook;
   
   USE guestbook;
   
   CREATE TABLE entries (guestName VARCHAR(255), content VARCHAR(255), entryID INT NOT NULL AUTO_INCREMENT, PRIMARY KEY(entryID));
   
   INSERT INTO entries (guestName, content) values ("first guest", "I got here!");
   INSERT INTO entries (guestName, content) values ("second guest", "Me too!");
   

3. Periksa apakah data berhasil di-commit:

   SELECT * FROM entries;
   

   Verifikasi bahwa dua baris data ditampilkan.

4. Keluar dari shell MySQL:

   exit;
   

Pada tahap ini, Anda memiliki satu database yang menyertakan tabel dan beberapa data pengujian.

Mengubah instance utama menjadi instance database dengan ketersediaan tinggi (HA)

Anda hanya dapat mengonfigurasi Cloud SQL sebagai sistem HA regional, bukan sebagai sistem lintas regional. (Menyiapkan replika baca lintas region berbeda dengan mengonfigurasi Cloud SQL sebagai sistem lintas regional.) Untuk mengetahui informasi selengkapnya, baca Mengaktifkan dan menonaktifkan ketersediaan tinggi pada instance.

• Di Cloud Shell, buat instance Cloud SQL dengan ketersediaan tinggi (HA):

  gcloud sql instances patch $primary_name \
      --availability-type REGIONAL \
      --enable-bin-log \
      --backup-start-time=$primary_backup_start_time
  

Menambahkan replika baca lintas region untuk DR dengan update otomatis

Langkah-langkah berikut sudah cukup untuk membuat replika baca lintas region untuk tutorial ini:

1. Di Cloud Shell, siapkan replika baca lintas region:

   gcloud sql instances create $cross_region_replica_name \
       --master-instance-name=$primary_name \
       --region=$cross_region_replica_region
   

2. (Opsional) Untuk memeriksa apakah database telah direplikasi, buka halaman Instance Cloud SQL di Konsol Google Cloud.

   Buka Instance

   

   Konsol Google Cloud menunjukkan bahwa instance utama (instance-1) diaktifkan untuk HA dan replika baca lintas region (instance-3 ) ada.

3. Login ke replika baca lintas region dengan menggunakan sandi root yang sama untuk kata sandi utama:

   gcloud sql connect $cross_region_replica_name --user=root
   

4. Pada perintah MySQL, pilih data untuk memastikan bahwa replikasi berfungsi:

   USE guestbook;
   
   SELECT * FROM entries;
   

5. Keluar dari shell MySQL:

   exit;
   

Untuk mengetahui detail tentang cara menyiapkan replika baca lintas region yang lengkap, lihat dokumentasi Cloud SQL

Untuk database besar dalam lingkungan produksi, sebaiknya cadangkan database utama dan buat replika baca lintas region dari cadangan. Langkah ini membantu mengurangi waktu yang diperlukan replika baca untuk disinkronkan dengan database utama. Proses ini dijelaskan di bagian berikutnya. Namun, Anda dapat memilih untuk melewati langkah ini dan melanjutkan ke Fase 2.

Menambahkan replika baca lintas region berdasarkan file dump

Salah satu cara untuk mengoptimalkan pembuatan replika baca lintas region adalah dengan menyinkronkan replika dari status database utama yang konsisten sebelumnya, bukan menyinkronkan pada saat mengakses status utama baru. Pengoptimalan ini memerlukan pembuatan file dump yang digunakan replika sebagai status awal.

Untuk mengetahui langkah-langkah membuat replika berdasarkan file dump, baca bagian Mereplikasi dari server eksternal ke Cloud SQL (v1.1). Pendekatan ini dapat bermanfaat untuk database produksi yang besar. Namun, tutorial ini melewati langkah ini karena set data pengujian cukup kecil untuk replikasi lengkap.

Tahap 2: Menyimulasikan bencana (pemadaman region)

Pada fase ini, Anda akan menyimulasikan pemadaman layanan region utama dalam setelan produksi dengan membuat database utama tidak tersedia.

Memeriksa keterlambatan replika baca lintas region

Pada langkah-langkah berikut, Anda akan menentukan jeda replikasi dari replika baca lintas-region:

1. Di konsol Google Cloud, buka halaman Instance Cloud SQL.

   Buka Instance

2. Klik replika baca (instance-3).

3. Di menu drop-down metrik, klik Jeda Replikasi:

   

   Metrik ini berubah menjadi Jeda Replikasi. Grafik tidak menunjukkan penundaan:

   

Idealnya, jeda replikasi adalah nol saat pemadaman layanan region utama terjadi, karena penundaan nol memastikan bahwa semua transaksi direplikasi. Jika tidak nol, beberapa transaksi mungkin tidak direplikasi. Dalam hal ini, replika baca lintas region tidak akan berisi semua transaksi yang dilakukan pada replika baca utama.

Membuat instance utama tidak tersedia

Pada langkah-langkah berikut, Anda akan menyimulasikan bencana dengan menghentikan yang utama. Jika replika baca lintas region dilampirkan ke replika baca tersebut, Anda harus melepaskan replika terlebih dahulu. Jika tidak, Anda tidak dapat menghentikan instance Cloud SQL.

1. Di Cloud Shell, hapus replika baca lintas region dari replika baca utama:

   gcloud sql instances patch $cross_region_replica_name \
       --no-enable-database-replication
   

   Jika diminta, terima opsi untuk melanjutkan.

2. Hentikan instance database utama:

   gcloud sql instances patch $primary_name --activation-policy NEVER
   

Mengimplementasikan DR

1. Di Cloud Shell, promosikan replika baca lintas region ke instance mandiri:

   gcloud sql instances promote-replica $cross_region_replica_name
   

   Jika diminta, terima opsi untuk melanjutkan. Halaman Instance Cloud SQL menampilkan replika baca lintas region sebelumnya (instance-3) sebagai primer baru, dan primer sebelumnya (instance-1) seperti yang dihentikan:

   

   Setelah mempromosikan replika baca lintas region sebagai replika baca utama baru, Anda akan mengaktifkannya untuk HA. Sebagai praktik terbaik, Anda harus memperbarui variabel ingkungan dengan penamaan yang tepat.

2. Update variabel lingkungan:

   export former_primary_name=$primary_name
   export primary_name=$cross_region_replica_name
   export primary_tier=db-n1-standard-2
   export primary_region=$cross_region_replica_region
   export primary_root_password=my-root-password
   export primary_backup_start_time=22:00
   export cross_region_replica_name=instance-5
   export cross_region_replica_region=us-west3
   

3. Mulai instance utama baru:

   gcloud sql instances patch $primary_name --activation-policy ALWAYS
   

4. Aktifkan instance utama baru sebagai instance regional dengan ketersediaan tinggi (HA):

   gcloud sql instances patch $primary_name \
       --availability-type REGIONAL \
       --enable-bin-log \
       --backup-start-time=$backup_start_time
   

5. Buat replika baca lintas region di region ketiga:

   gcloud sql instances create $cross_region_replica_name \
       --master-instance-name=$primary_name \
       --region=$cross_region_replica_region
   

   Pada langkah sebelumnya, Anda akan menetapkan variabel lingkungan cross_region_replica_region ke us-west3.

   Setelah failover selesai, halaman Instance Cloud SQL di konsol Google Cloud akan menunjukkan bahwa instance utama yang baru (instance-3) diaktifkan sebagai HA dan memiliki replika baca lintas region (instance-5):

   

6. (Opsional) Jika Anda memiliki cadangan reguler, ikuti proses yang dijelaskan sebelumnya untuk menyinkronkan cadangan utama yang baru dengan versi cadangan terbaru.

7. (Opsional) Jika Anda menggunakan proxy Cloud SQL, konfigurasikan proxy tersebut untuk menggunakan proxy utama yang baru agar dapat melanjutkan pemrosesan aplikasi.

Menangani pemadaman layanan region singkat

Ada kemungkinan bahwa pemadaman layanan yang memicu failover akan diselesaikan sebelum failover selesai. Dalam hal ini, Anda dapat membatalkan proses failover dan terus menggunakan instance Cloud SQL utama asli di region tempat pemadaman layanan terjadi.

Bergantung pada status spesifik dari proses failover, replika baca lintas region mungkin telah dipromosikan. Jika demikian, Anda harus menghapusnya dan membuat ulang replika baca lintas region.

Hapus instance utama asli untuk menghindari situasi split-brain

Untuk menghindari situasi split-brain, Anda perlu menghapus versi instance utama yang asli (atau membuatnya tidak dapat diakses oleh klien database).

Setelah failover, situasi split-brain dapat terjadi saat klien menulis ke database instance utama asli dan database instance utama baru secara bersamaan. Dalam hal ini, konten kedua database tidak konsisten. Setelah failover, database instance utama asli sudah tidak berlaku lagi dan tidak boleh menerima traffic baca atau tulis.

• Di Cloud Shell, hapus versi instance utama asli:

  gcloud sql instances delete $former_primary_name
  

  Jika diminta, terima opsi untuk melanjutkan.

  Di Konsol Google Cloud, halaman Instance Cloud SQL tidak lagi menampilkan instance utama asli (instance-1) sebagai bagian dari deployment:

  

Fase 3: Menerapkan penggantian

Untuk menerapkan penggantian ke region asli (R1) setelah tersedia, ikuti proses yang sama seperti yang dijelaskan di Fase 2. Proses tersebut diringkas sebagai berikut:

1. Buat replika baca lintas region kedua di region asli (R1). Pada tahap ini, elemen utama memiliki dua replika baca lintas region, satu di region R3, dan satu di region R1.

2. Promosikan replika baca lintas region di R1 sebagai primer akhir.

3. Aktifkan HA untuk primer akhir.

4. Buat replika baca lintas region dari primer final di us-west2.

5. Untuk menghindari situasi split-brain, hapus semua instance yang tidak lagi diperlukan (replika baca primer asli dan lintas region di R3).

Seperti yang telah dibahas sebelumnya, sebaiknya buat cadangan awal yang berisi status awal yang ditentukan untuk database utama yang baru.

Deployment akhir sekarang memiliki HA primer (dengan nama instance-6) dan replika baca lintas region (dengan nama instance-8).

Membandingkan kelebihan dan kekurangan DR manual versus otomatis

Tabel berikut membahas kelebihan dan kekurangan menerapkan proses DR, baik secara manual maupun otomatis. Tujuannya bukan untuk menentukan pendekatan yang benar dibandingkan dengan yang salah, melainkan memberikan kriteria untuk membantu Anda menentukan pendekatan terbaik sesuai kebutuhan.

Eksekusi manual	Eksekusi otomatis
Kelebihan: Anda memiliki kontrol yang ketat atas setiap langkah. Anda dapat segera melihat, mengatasi, dan mendokumentasikan masalah apa pun dalam prosesnya. Anda dapat melihat dan meninjau setiap langkah proses selama failover.	Kelebihan: Anda dapat mengimplementasikan dan menguji proses failover. Otomatisasi menawarkan implementasi tercepat dan meminimalkan penundaan. Implementasi tidak bergantung pada operator manusia, pengetahuannya, dan ketersediaannya.
Kekurangan: Menerapkan langkah-langkah proses secara manual akan memperlambat proses. Kesalahan pengetikan manusia dapat menyebabkan masalah. Pengujian proses ini biasanya melibatkan beberapa peran dan waktu, yang mungkin mencegah pengujian rutin.	Kekurangan: Jika terjadi error yang tidak terduga, Anda harus melakukan debug selama failover produksi. Jika mengalami error selama proses ini, Anda memerlukan skrip untuk melanjutkan (dipulihkan) dari bagian terakhir proses. Pengetahuan skrip dan implementasinya yang memadai diperlukan untuk memahami perilaku skrip, terutama dalam situasi error.

Sebagai praktik terbaik, sebaiknya Anda memulai dengan implementasi manual. Kemudian, jalankan implementasi tersebut secara sukarela dan rutin (sebaiknya dalam produksi) untuk memastikan bahwa proses manual berjalan dengan baik dan semua anggota tim mengetahui peran dan tanggung jawabnya. Sebaiknya Anda menjelaskan proses manual dalam dokumen proses langkah demi langkah. Setelah setiap implementasi, Anda harus mengonfirmasi atau meningkatkan kualitas dokumen proses.

Setelah Anda meningkatkan kualitas prosesnya dan yakin bahwa proses tersebut dapat diandalkan, Anda akan menentukan apakah akan mengotomatiskan prosesnya atau tidak. Jika memilih dan mengimplementasikan proses otomatis, Anda perlu menguji proses tersebut secara berkala dalam produksi untuk memastikan bahwa Anda dapat menerapkannya dengan andal.

Pembersihan

Agar tidak menimbulkan biaya pada akun Google Cloud Anda untuk resource yang digunakan dalam tutorial ini, Anda dapat menghapus project Google Cloud yang Anda buat untuk tutorial ini.

Menghapus project

Perhatian: Menghapus project memiliki efek berikut:

• Semua hal dalam project akan dihapus. Jika menggunakan project yang sudah ada untuk tugas dalam dokumen ini, saat Anda menghapusnya, pekerjaan lain yang telah Anda lakukan dalam project tersebut juga akan terhapus.
• Project ID kustom hilang. Saat membuat project ini, Anda mungkin telah membuat project ID kustom yang ingin digunakan di masa mendatang. Untuk mempertahankan URL yang menggunakan project ID, seperti URL appspot.com, hapus resource yang dipilih di dalam project, bukan menghapus seluruh project.

Jika Anda berencana mempelajari berbagai arsitektur, tutorial, atau panduan memulai, menggunakan kembali project dapat membantu agar Anda tidak melampaui batas kuota project.

1. Di konsol Google Cloud, buka halaman Manage resource.

   Buka Manage resource

2. Pada daftar project, pilih project yang ingin Anda hapus, lalu klik Delete.
3. Pada dialog, ketik project ID, lalu klik Shut down untuk menghapus project.

Langkah selanjutnya

• Baca pemulihan dari bencana (disaster recovery) Cloud SQL.
• Baca pemulihan dari bencana (disaster recovery) untuk MySQL di Compute Engine.
• Pelajari arsitektur pemulihan dari bencana untuk pemadaman infrastruktur cloud.
• Pelajari arsitektur referensi, diagram, dan praktik terbaik tentang Google Cloud. Lihat Cloud Architecture Center kami.