Disaster recovery Cloud SQL untuk MySQL: Proses failover dan fallback lengkap

Tutorial ini menjelaskan proses failover dan fallback disaster recovery (DR) lengkap di Cloud SQL untuk MySQL menggunakan replika baca lintas region.

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

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

Untuk membaca ringkasan cara kerja disaster recovery SQL, lihat Tentang 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.
Memahami langkah-langkah memulihkan deployment awal menggunakan fallback dengan Cloud SQL untuk MySQL.

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

Biaya

Dalam dokumen ini, Anda akan menggunakan komponen Google Cloudyang dapat ditagih berikut:

Cloud SQL

Untuk membuat perkiraan biaya berdasarkan proyeksi penggunaan Anda, gunakan kalkulator harga.

Pengguna Google Cloud baru 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, baca bagian Pembersihan.

Sebelum memulai

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
Roles required to select or create a project
- Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
- Create a project: To create a project, you need the Project Creator (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.
Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector
Verify that billing is enabled for your Google Cloud project.

In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell

Tahap 1: Menyiapkan instance database HA untuk DR

Tahap berikut (1-3) akan memandu Anda menyelesaikan proses failover dan fallback. 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). Di 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 variabel contoh ini sesuai kebutuhan.

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

Tahap awal
Nama instance	Peran	Region
`instance-1`	Utama	`us-west1`
`instance-2`	Standby	`us-west1`
`instance-3`	Replika baca lintas region	`us-west2`

Tahap bencana
Nama instance	Peran	Region
`instance-3`	Utama	`us-west2`
`instance-4`	Standby	`us-west2`
`instance-5`	Replika baca lintas region	`us-west3`
`instance-6`	Replika baca lintas region	`us-west1`

Tahap fallback (final)
Nama instance	Peran	Region
`instance-6`	Utama	`us-west1`
`instance-7`	Standby	`us-west1`
`instance-8`	Replika baca lintas region	`us-west2`

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

Tabel di atas mencantumkan nama instance standby. Meskipun tidak menjalankan failover HA, tutorial ini mencantumkan nama-nama instance standby agar lengkap.

Tahap fallback membuat ulang deployment asli tahap awal di region asli yang sama. Namun, dalam fallback, nama instance harus diubah karena nama aslinya tidak akan langsung tersedia meskipun instance asli telah dihapus. Agar instance dapat dibuat dengan cepat pada tahap fallback, Anda harus menggunakan nama instance yang berbeda dengan nama yang digunakan pada tahap awal.

Di Cloud Shell, tetapkan variabel lingkungan yang didasarkan pada spesifikasi dalam tabel di atas:
```
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 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

Di Cloud Shell, buat instance tunggal Cloud SQL:

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

Perintah gcloud dijeda hingga instance dibuat.

Tetapkan sandi root:

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

Membuat database utama

Di Cloud Shell, login ke shell MySQL dan masukkan sandi root pada prompt:
```
gcloud sql connect $primary_name --user=root
```

Pada prompt 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!");

Periksa apakah data berhasil di-commit:
```
SELECT * FROM entries;
```
Verifikasi bahwa dua baris data ditampilkan.
Keluar dari shell MySQL:
```
exit;
```

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

Mengubah instance utama menjadi instance database 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 dukungan 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 menunjukkan cara membuat replika baca lintas region untuk tutorial ini:

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

(Opsional) Untuk memeriksa apakah database sudah direplikasi, di KonsolGoogle Cloud , buka halaman Instances Cloud SQL.

Buka Instances

Konsol Google Cloud menunjukkan bahwa instance utama (instance-1) diaktifkan untuk HA dan replika baca lintas region (instance-3) ada.
Login ke replika baca lintas region menggunakan sandi root yang sama dengan yang digunakan untuk instance utama:
```
gcloud sql connect $cross_region_replica_name --user=root
```
Pada prompt MySQL, pilih data untuk memastikan bahwa replikasi berfungsi:
```
USE guestbook;

SELECT * FROM entries;
```
Keluar dari shell MySQL:
```
exit;
```

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

Untuk database berskala besar di lingkungan produksi, sebaiknya cadangkan database utama dan buat replika baca lintas region dari cadangan tersebut. Langkah ini membantu mengurangi waktu yang diperlukan untuk menyinkronkan replika baca dengan database utama. Proses ini dijelaskan di bagian berikutnya. Namun, Anda dapat melewati langkah ini dan melanjutkan ke Tahap 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 instance 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 Membuat replika dari server eksternal ke Cloud SQL (v1.1). Pendekatan ini dapat bermanfaat untuk database produksi berukuran besar. Namun, tutorial ini melewati langkah ini karena set data pengujiannya cukup kecil untuk replikasi lengkap.

Tahap 2: Menyimulasikan bencana (pemadaman layanan region)

Pada tahap ini, Anda akan menyimulasikan pemadaman layanan region utama di lingkungan produksi dengan menjadikan database utama tidak tersedia.

Memeriksa jeda replika baca lintas region

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

Di Konsol Google Cloud , buka halaman Instances Cloud SQL.

Buka Instances
Klik replika baca (instance-3).
Di menu drop-down metrik, klik Replication Lag:

Metrik ini berubah menjadi Replication Lag. Grafik menunjukkan tidak ada jeda:

Idealnya, jeda replikasi adalah nol saat pemadaman layanan region utama terjadi, karena jeda nol memastikan bahwa semua transaksi direplikasi. Jika tidak nol, sebagian transaksi mungkin tidak direplikasi. Dalam kasus ini, replika baca lintas region tidak akan berisi semua transaksi yang telah di-commit di instance utama.

Menjadikan instance utama tidak tersedia

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

Di Cloud Shell, hapus replika baca lintas region dari instance utama:
```
gcloud sql instances patch $cross_region_replica_name \
    --no-enable-database-replication
```
Saat diminta, terima opsi untuk melanjutkan.

Hentikan instance database utama:

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

Mengimplementasikan DR

Di Cloud Shell, promosikan replika baca lintas region menjadi instance mandiri:
```
gcloud sql instances promote-replica $cross_region_replica_name
```
Saat diminta, terima opsi untuk melanjutkan. Halaman Instances Cloud SQL menampilkan replika baca lintas region sebelumnya (instance-3) sebagai instance utama baru, dan instance utama sebelumnya (instance-1) dihentikan:

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

Perbarui 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

Mulai instance utama baru:

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

Aktifkan instance utama baru sebagai instance regional HA:

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

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 menetapkan variabel lingkungan cross_region_replica_region ke us-west3.

Setelah failover selesai, halaman Instances Cloud SQL di Konsol Google Cloud menunjukkan bahwa instance utama baru (instance-3) diaktifkan sebagai HA dan memiliki replika baca lintas region (instance-5):
(Opsional) Jika Anda rutin melakukan pencadangan, ikuti proses yang dijelaskan sebelumnya untuk menyinkronkan instance utama baru dengan versi cadangan terbaru.
(Opsional) Jika Anda menggunakan proxy Cloud SQL, konfigurasi proxy tersebut untuk menggunakan instance utama baru agar dapat melanjutkan pemrosesan aplikasi.

Menangani pemadaman layanan region singkat

Ada kemungkinan pemadaman layanan yang memicu failover dapat 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 proses failover, replika baca lintas region mungkin telah dipromosikan. Jika demikian, Anda harus menghapusnya dan membuat ulang replika baca lintas region.

Menghapus instance utama asli untuk menghindari situasi split-brain

Untuk menghindari situasi split-brain, Anda perlu menghapus instance utama asli (atau menjadikannya 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, isi kedua database menjadi tidak konsisten. Setelah failover, database instance utama asli sudah tidak berlaku lagi dan tidak boleh menerima traffic baca atau tulis.

Di Cloud Shell, hapus instance utama asli:
```
gcloud sql instances delete $former_primary_name
```
Saat diminta, terima opsi untuk melanjutkan.

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

Tahap 3: Menerapkan fallback

Untuk menerapkan fallback ke region asli (R1) setelah tersedia, ikuti proses yang sama seperti yang dijelaskan di Tahap 2. Berikut ringkasan proses tersebut:

Buat replika baca lintas region kedua di region asli (R1). Pada tahap ini, instance utama memiliki dua replika baca lintas region, satu di region R3, dan satu di region R1.
Promosikan replika baca lintas region di R1 menjadi instance utama akhir.
Aktifkan HA untuk instance utama akhir.
Buat replika baca lintas region dari instance utama akhir di us-west2.
Untuk menghindari situasi split-brain, hapus semua instance yang tidak lagi diperlukan (instance utama asli dan replika baca 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 kini memiliki instance utama HA (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 dan yang salah, melainkan memberikan kriteria agar Anda dapat menentukan pendekatan terbaik sesuai kebutuhan Anda.

Eksekusi manual	Eksekusi otomatis
Kelebihan: Anda memiliki kontrol yang ketat atas setiap langkah. Anda dapat segera menemukan, mengatasi, dan mendokumentasikan masalah apa pun yang ditemukan di sepanjang proses. 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: Implementasi langkah-langkah proses secara manual akan memperlambat proses. Kesalahan pengetikan manual dapat menyebabkan masalah. Pengujian proses biasanya melibatkan beberapa peran dan memakan waktu, yang dapat menghambat pengujian rutin.	Kekurangan: Jika terjadi error yang tidak terduga, Anda harus melakukan debug selama failover produksi. Jika terjadi error selama proses ini, Anda memerlukan skrip agar dapat melanjutkan (memulihkan) dari bagian terakhir proses. Pengetahuan yang memadai tentang skrip dan implementasinya 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 di lingkungan produksi) untuk memastikan proses manual berjalan lancar dan semua anggota tim mengetahui peran dan tanggung jawab mereka. Sebaiknya jelaskan proses manual Anda dalam dokumen proses langkah demi langkah. Setelah setiap implementasi dilakukan, Anda harus mengonfirmasi atau menyempurnakan dokumen proses tersebut.

Setelah menyempurnakan proses dan yakin dengan keandalannya, tentukan apakah Anda akan mengotomatiskan proses tersebut atau tidak. Jika memilih dan mengimplementasikan proses otomatis, Anda perlu menguji proses tersebut secara rutin di lingkungan produksi untuk memastikan bahwa Anda dapat menerapkannya dengan andal.

Pembersihan

Agar akun Google Cloud Anda tidak dikenai biaya untuk resource yang digunakan dalam tutorial ini, hapus project Google Cloud yang Anda buat untuk tutorial ini.

Menghapus project

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
In the project list, select the project that you want to delete, and then click Delete.
In the dialog, type the project ID, and then click Shut down to delete the project.

Langkah berikutnya

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