Men-deploy Microsoft SQL Server untuk pemulihan bencana multi-regional

Last reviewed 2020-08-21 UTC

---

Tutorial ini menjelaskan cara men-deploy dan mengelola sistem database Microsoft SQL Server di dua region Google Cloud sebagai solusi pemulihan dari bencana (DR) dan cara mengalihkan dari instance database yang gagal ke instance yang beroperasi normal. Untuk tujuan dokumen ini, bencana adalah peristiwa ketika database utama gagal atau menjadi tidak tersedia.

Database utama dapat gagal jika region tempat database tersebut berada tidak dapat diakses atau menjadi tidak dapat diakses. Meskipun suatu region tersedia dan beroperasi secara normal, database utama bisa gagal karena error sistem. Dalam kasus ini, pemulihan dari bencana (disaster recovery) adalah proses penyediaan database sekunder bagi klien untuk diproses lebih lanjut.

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

Tujuan

• Deploy lingkungan pemulihan dari bencana multi-regional di Google Cloud menggunakan Grup Ketersediaan AlwaysOn Microsoft SQL Server.
• Simulasikan peristiwa bencana dan lakukan proses pemulihan dari bencana (disaster recovery) yang lengkap untuk memvalidasi konfigurasi pemulihan dari bencana (disaster recovery).

Biaya

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

• Compute Engine
• VM SQL Server

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

Untuk tutorial ini, Anda memerlukan proyek Google Cloud. Anda dapat membuat project baru, atau memilih project yang sudah Anda buat:

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

Memahami pemulihan dari bencana (disaster recovery)

Di Google Cloud, pemulihan dari bencana (disaster recovery/DR) bertujuan menyediakan kontinuitas pemrosesan, terutama saat suatu region gagal atau tidak dapat diakses. Untuk sistem seperti sistem pengelolaan database, Anda menerapkan DR dengan men-deploy sistem di minimal dua region. Dengan penyiapan ini, sistem akan terus beroperasi jika satu region menjadi tidak tersedia.

Pemulihan dari bencana (disaster recovery) sistem database

Proses penyediaan database sekunder ketika instance database utama gagal disebut pemulihan bencana database (atau DR database). Untuk pembahasan mendetail tentang konsep ini, lihat Pemulihan dari bencana (disaster recovery) untuk Microsoft SQL Server. Idealnya, status database sekunder konsisten dengan database utama saat database utama tidak tersedia, atau database sekunder hanya kehilangan serangkaian kecil transaksi terbaru dari database utama.

Arsitektur pemulihan dari bencana (disaster recovery)

Untuk Microsoft SQL Server, diagram berikut menunjukkan arsitektur minimal yang mendukung DR database.

Gambar 1. Arsitektur pemulihan dari bencana standar dengan Microsoft SQL Server.

Arsitektur ini berfungsi sebagai berikut:

• Dua instance Microsoft SQL Server (instance utama dan instance standby) terletak di region yang sama (R1), tetapi zona yang berbeda (zona A dan B). Kedua instance di R1 mengoordinasikan statusnya menggunakan mode commit sinkron. Mode sinkron digunakan karena mendukung ketersediaan tinggi dan mempertahankan status data yang konsisten.
• Satu instance Microsoft SQL Server (instance pemulihan sekunder atau pemulihan dari bencana) terletak di region kedua (R2). Untuk DR, instance sekunder di R2 disinkronkan dengan instance utama di R1 menggunakan mode commit asinkron. Mode asinkron digunakan karena performanya (tidak memperlambat pemrosesan commit di instance utama).

Dalam diagram sebelumnya, arsitektur menampilkan grup ketersediaan. Grup ketersediaan, jika digunakan dengan pemroses, memberikan string koneksi yang sama ke klien jika klien dilayani oleh yang berikut ini:

• Instance utama
• Instance standby (setelah kegagalan zona)
• Instance sekunder (setelah kegagalan region dan setelah instance sekunder menjadi instance utama baru)

Pada varian arsitektur di atas, Anda men-deploy dua instance yang berada di region pertama (R1) ke zona yang sama. Pendekatan ini dapat meningkatkan performa, tetapi tidak terlalu tersedia; pemadaman zona tunggal mungkin diperlukan untuk memulai proses DR.

Proses pemulihan dari bencana (disaster recovery) dasar

Proses DR dimulai saat suatu region menjadi tidak tersedia dan database utama gagal melanjutkan pemrosesan di region operasional lain. Proses DR menetapkan langkah-langkah operasional yang harus dilakukan, baik secara manual maupun otomatis, untuk memitigasi kegagalan region dan menetapkan instance utama yang berjalan di region yang tersedia.

Proses DR database dasar terdiri dari langkah-langkah berikut:

1. Region pertama (R1), yang menjalankan instance database utama, tidak akan tersedia.
2. Tim operasi mengenali dan secara resmi mengonfirmasi bencana, dan memutuskan apakah failover diperlukan.
3. Jika failover diperlukan, instance database sekunder di region kedua (R2) akan dijadikan instance utama baru.
4. Klien melanjutkan pemrosesan pada database utama yang baru dan mengakses instance utama di R2.

Meskipun proses dasar ini membuat database utama yang berfungsi lagi, proses tersebut tidak menetapkan arsitektur DR lengkap, di mana proses utama yang baru memiliki instance database cadangan dan sekunder.

Proses pemulihan dari bencana (disaster recovery) lengkap

Proses DR yang lengkap memperluas proses DR dasar dengan menambahkan langkah-langkah untuk membangun arsitektur DR lengkap setelah failover. Diagram berikut menunjukkan arsitektur DR database yang lengkap.

Gambar 2. Pemulihan dari bencana (disaster recovery) dengan region utama yang tidak tersedia (R1).

Arsitektur DR database yang lengkap ini berfungsi sebagai berikut:

1. Region pertama (R1), yang menjalankan instance database utama, tidak akan tersedia.
2. Tim operasi mengenali dan secara resmi mengakui bencana tersebut dan memutuskan apakah failover diperlukan.
3. Jika failover diperlukan, instance database sekunder di region kedua (R2) akan dijadikan instance utama.
4. Instance sekunder lainnya, instance standby baru, dibuat dan dimulai di R2 dan ditambahkan ke instance utama. Instance standby berada di zona yang berbeda dengan instance utama. Database utama kini terdiri dari dua instance (utama dan standby) yang sangat tersedia.
5. Di region ketiga (R3), instance database sekunder (standby) baru akan dibuat dan dimulai. Instance sekunder ini terhubung secara asinkron ke instance utama yang baru di R2. Pada tahap ini, arsitektur pemulihan bencana awal dibuat ulang dan beroperasi.

Penggantian ke region yang dipulihkan

Setelah region pertama (R1) dikembalikan online, region tersebut dapat menghosting database sekunder baru. Jika R1 segera tersedia, Anda dapat menerapkan langkah 5 dalam proses pemulihan lengkap di R1, bukan R3 (region ketiga). Dalam hal ini, region ketiga tidak diperlukan.

Diagram berikut menunjukkan arsitektur jika R1 tersedia tepat waktu.

Gambar 3. Pemulihan dari bencana (disaster recovery) setelah region R1 yang gagal tersedia lagi.

Dalam arsitektur ini, langkah-langkah pemulihannya sama dengan yang diuraikan sebelumnya dalam Proses pemulihan dari bencana (disaster recovery) lengkap dengan perbedaan, yaitu R1 menjadi lokasi untuk instance sekunder, bukan R3.

Memilih edisi SQL Server

Tutorial ini mendukung versi Microsoft SQL Server berikut:

• SQL Server 2016 Enterprise Edition
• SQL Server 2017 Enterprise Edition
• SQL Server 2019 Enterprise Edition

Tutorial ini menggunakan fitur Grup Ketersediaan AlwaysOn di SQL Server.

Jika tidak memerlukan database utama Microsoft SQL Server yang sangat tersedia (HA), dan satu instance database sudah cukup sebagai instance utama, Anda dapat menggunakan versi SQL Server berikut:

• SQL Server 2016 Standard Edition
• SQL Server 2017 Standard Edition
• SQL Server 2019 Standard Edition

SQL Server versi 2016, 2017, dan 2019 telah menginstal Microsoft SQL Server Management Studio pada image; Anda tidak perlu menginstalnya secara terpisah. Namun, dalam lingkungan produksi, sebaiknya instal satu instance Microsoft SQL Server Management Studio pada VM terpisah di setiap region. Jika menyiapkan lingkungan dengan ketersediaan tinggi (HA), Anda harus menginstal Microsoft SQL Server Management Studio satu kali untuk setiap zona guna memastikan bahwa lingkungan tersebut tetap tersedia jika zona lain menjadi tidak tersedia.

Menyiapkan Microsoft SQL Server untuk DR multi-regional

Bagian ini menggunakan gambar sql-ent-2016-win-2016 untuk Microsoft SQL Server 2016 Enterprise Edition. Jika Anda menginstal Microsoft SQL Server 2017 Enterprise Edition, gunakan sql-ent-2017-win-2016. Untuk Microsoft SQL Server 2019 Enterprise Edition, gunakan sql-ent-2019-win-2019. Untuk daftar lengkap image, lihat Gambar.

Menyiapkan cluster ketersediaan tinggi dua instance

Untuk menyiapkan arsitektur DR database multi-regional untuk SQL Server, Anda harus terlebih dahulu membuat cluster ketersediaan tinggi (HA) dua instance di suatu region. Satu instance berfungsi sebagai instance utama, dan instance lainnya berfungsi sebagai sekunder. Untuk menyelesaikan langkah ini, ikuti petunjuk di Mengonfigurasi Grup Ketersediaan AlwaysOn SQL Server. Tutorial ini menggunakan us-central1 untuk region utama (disebut sebagai R1). Sebelum memulai, tinjau pertimbangan berikut.

Pertama, jika mengikuti langkah-langkah dalam Mengonfigurasi Grup Ketersediaan AlwaysOn SQL Server, Anda akan membuat dua instance SQL Server di zona yang sama (us-central1-f). Penyiapan ini tidak melindungi Anda dari kegagalan us-central1-f. Oleh karena itu, untuk memberikan dukungan HA, Anda men-deploy satu instance SQL Server (cluster-sql1) di us-central1-c, dan instance kedua (cluster-sql2) di us-central1-f. Langkah-langkah di bagian berikutnya (tentang menambahkan instance sekunder untuk pemulihan dari bencana) mengasumsikan penyiapan deployment ini.

Kedua, langkah dalam Mengonfigurasi Grup Ketersediaan AlwaysOn SQL Server termasuk menjalankan pernyataan ini:

BACKUP DATABASE TestDB to disk = '\\cluster-sql2\SQLBackup\TestDB.bak' WITH INIT

Pernyataan ini menyebabkan instance standby gagal. Sebagai gantinya, jalankan perintah berikut (nama file cadangan berbeda):

BACKUP DATABASE TestDB to disk = '\\cluster-sql2\SQLBackup\TestDB-backup.bak' WITH INIT

Ketiga, langkah-langkah di bagian Mengonfigurasi Grup Ketersediaan AlwaysOn SQL Server akan membuat direktori cadangan. Cadangan ini hanya boleh digunakan saat Anda pertama kali menyinkronkan instance utama dan standby, bukan setelahnya. Pendekatan alternatif untuk membuat direktori cadangan adalah dengan memilih Automatic seeding (Penyebaran otomatis) dalam langkah-langkah ini. Pendekatan ini menyederhanakan proses pengaturan.

Keempat, jika database tidak disinkronkan, jalankan perintah berikut di cluster-sql2:

ALTER DATABASE [TestDB] SET HADR AVAILABILITY GROUP = [cluster-ag]

Kelima, untuk keperluan tutorial ini, Anda membuat satu pengontrol domain di us-central1-f, seperti yang ditunjukkan diagram berikut.

Gambar 4. Arsitektur pemulihan dari bencana standar yang diterapkan dalam tutorial ini.

Meskipun Anda menerapkan arsitektur sebelumnya untuk tutorial ini, praktik terbaiknya adalah menyiapkan pengontrol domain di lebih dari satu zona. Pendekatan ini memastikan Anda membuat arsitektur database yang mendukung HA dan DR. Misalnya, jika terjadi pemadaman di satu zona, zona tersebut tidak menjadi titik tunggal kegagalan untuk arsitektur yang di-deploy.

Menambahkan instance sekunder untuk pemulihan dari bencana (disaster recovery)

Selanjutnya, Anda akan menyiapkan instance SQL Server ketiga (instance sekunder yang bernama cluster-sql3), beserta jaringan:

1. Di Cloud Shell, dengan virtual private cloud (VPC) yang sama dengan yang Anda gunakan untuk region utama, buat subnet di region sekunder (us-east1):

   gcloud compute networks subnets create wsfcsubnet4 --network wsfcnet \
       --region us-east1 --range 10.3.0.0/24
   

2. Ubah aturan firewall yang disebut allow-internal-ports agar subnet baru dapat menerima traffic:

   gcloud compute firewall-rules update allow-internal-ports \
       --source-ranges 10.0.0.0/24,10.1.0.0/24,10.2.0.0/24,10.3.0.0/24
   

   Aturan allow-internal-ports disertakan dalam langkah-langkah dari instructions yang Anda ikuti sebelumnya.

3. Buat instance SQL Server:

   gcloud compute instances create cluster-sql3 --machine-type n1-highmem-4 \
       --boot-disk-type pd-ssd --boot-disk-size 200GB \
       --image-project windows-sql-cloud --image-family sql-ent-2016-win-2016 \
       --zone us-east1-b \
       --network-interface "subnet=wsfcsubnet4,private-network-ip=10.3.0.4,aliases=10.3.0.5;10.3.0.6" \
       --can-ip-forward --metadata sysprep-specialize-script-ps1="Install-WindowsFeature Failover-Clustering -IncludeManagementTools;"
   

4. Tetapkan sandi Windows untuk instance SQL Server baru:

   1. Di konsol Google Cloud, buka halaman Compute Engine.

      Buka Compute Engine

   2. Di kolom Connect untuk cluster Compute Engine cluster-sql3, pilih menu drop-down Setel sandi Windows.

   3. Setel nama pengguna dan sandi. Catat untuk digunakan nanti.

5. Klik RDP untuk terhubung ke instance cluster-sql3.

6. Masukkan nama pengguna dan sandi dari langkah 4, lalu klik OK.

7. Buka jendela Windows PowerShell sebagai administrator, lalu konfigurasikan DNS dan port terbuka:

   netsh interface ip set dns Ethernet static 10.2.0.100
   
   netsh advfirewall firewall add rule name="Open Port 5022 for Availability Groups" dir=in action=allow protocol=TCP localport=5022
   
   netsh advfirewall firewall add rule name="Open Port 1433 for SQL Server" dir=in action=allow protocol=TCP localport=1433
   

8. Tambahkan instance ke domain Windows:

   Add-Computer -DomainName "dbeng.com" -Credential "dbeng.com\Administrator" -Restart -Force
   

   Perintah ini menghentikan koneksi RDP Anda.

Tambahkan instance sekunder ke cluster failover

Selanjutnya, tambahkan instance sekunder (cluster-sql3) ke cluster failover Windows:

1. Hubungkan ke instance cluster-sql1 atau cluster-sql2 menggunakan RDP, dan login sebagai administrator.

2. Buka jendela PowerShell sebagai administrator dan tetapkan variabel untuk lingkungan cluster dalam tutorial ini:

   $node3 = "cluster-sql3"
   $nameWSFC = "cluster-dbclus" # Name of cluster
   

3. Tambahkan instance sekunder ke cluster:

   Get-Cluster | WHERE Name -EQ $nameWSFC | Add-ClusterNode -NoStorage -Name $node3
   

   Perintah ini mungkin memerlukan waktu beberapa saat untuk dijalankan. Karena prosesnya dapat berhenti merespons dan tidak kembali secara otomatis, tekan Enter sesekali.

4. Di node, aktifkan fitur AlwaysOn High Availability (Ketersediaan Tinggi AlwaysOn):

   Enable-SqlAlwaysOn -ServerInstance $node3 -Force
   

5. Buat dua folder di C:\SQLData dan C:\SQLLog untuk menyimpan data database dan file log:

   New-item -ItemType Directory "C:\SQLData"
   
   New-item -ItemType Directory "C:\SQLLog"
   

Sekarang node bergabung ke cluster failover.

Menambahkan instance sekunder ke grup ketersediaan yang ada

Selanjutnya, tambahkan instance SQL Server (instance sekunder) dan database ke grup ketersediaan:

1. Di salah satu dari tiga node instance (cluster-sql1, cluster-sql2, atau cluster-sql3), buka Microsoft SQL Server Management Studio dan hubungkan ke instance utama (cluster-sql1):

   1. Buka Penjelajah Objek.
   2. Pilih menu drop-down Hubungkan.
   3. Pilih Mesin Database.
   4. Dari menu drop-down Nama Server, pilih cluster-sql1. Jika cluster tidak tercantum, masukkan cluster pada kolom.

2. Click Kueri Baru.

3. Tempel perintah berikut untuk menambahkan alamat IP ke pemroses yang digunakan untuk node, lalu klik Jalankan:

   ALTER AVAILABILITY GROUP [cluster-ag] MODIFY LISTENER 'cluster-listene' (ADD IP ('10.3.0.6', '255.255.255.0'))
   

4. Di Penjelajah Objek, luaskan node AlwaysOn High Availability, lalu luaskan node Availability Groups (Grup Ketersediaan).

5. Klik kanan grup ketersediaan yang bernama cluster-ag, lalu pilih Tambahkan Replika.

6. Di halaman Introduction, klik node AlwaysOn High Availability, lalu klik node Availability Groups.

7. Di halaman Connect to Replicas(Hubungkan ke Replika), klik Connect untuk terhubung ke replika sekunder yang ada cluster-sql2.

8. Di halaman Specify Replicas(Tentukan Replika), klik Add Replica(Tambahkan Replika), lalu tambahkan node baru cluster-sql3. Jangan pilih Automatic Failover karena failover otomatis menyebabkan commit sinkron. Penyiapan tersebut melintasi batas wilayah, sehingga tidak kami rekomendasikan.

9. Di halaman Select Data Synchronization(Pilih Sinkronisasi Data), pilih Automatic seeding(Penyebaran otomatis).

   Karena tidak ada pemroses, halaman Validation menghasilkan peringatan, yang dapat Anda abaikan.

10. Selesaikan langkah-langkah wizard.

Mode failover untuk cluster-sql1 dan cluster-sql2 adalah otomatis, sedangkan mode manual untuk cluster-sql3. Perbedaan ini adalah salah satu cara untuk membedakan ketersediaan yang tinggi dari pemulihan dari bencana (disaster recovery).

Grup ketersediaan kini sudah siap. Anda telah mengonfigurasi dua node untuk ketersediaan tinggi dan node ketiga untuk pemulihan dari bencana (disaster recovery).

Menyimulasikan pemulihan dari bencana (disaster recovery)

Di bagian ini, Anda akan menguji arsitektur pemulihan dari bencana untuk tutorial ini dan mempertimbangkan implementasi DR opsional.

Menyimulasikan pemadaman layanan dan menjalankan failover DR

1. Menyimulasikan kegagalan (pemadaman) di region utama:

   1. Di Microsoft SQL Server Management Studio pada cluster-sql1, hubungkan ke cluster-sql1.

   2. Membuat tabel Setelah menambahkan replika di langkah berikutnya, verifikasi bahwa replika tersebut berfungsi dengan memeriksa apakah tabel ini ada.

      USE TestDB
      GO
      CREATE TABLE dbo.TestTable_Before_DR (ID INT NOT NULL)
      GO
      

   3. Di Cloud Shell, nonaktifkan kedua server di region utama (us-central1):

      gcloud compute instances stop cluster-sql2 --zone us-central1-f --quiet
      gcloud compute instances stop cluster-sql1 --zone us-central1-c --quiet
      

   Catatan: Cara alternatif untuk mengakibatkan kegagalan adalah dengan menghentikan VM yang menjalankan cluster-sql1 dan cluster-sql2. Pendekatan ini menyimulasikan kegagalan sulit, bukan penonaktifan instance biasa.

2. Di Microsoft SQL Server Management Studio pada cluster-sql3, hubungkan ke cluster-sql3.

3. Jalankan failover, dan tetapkan mode ketersediaan ke commit sinkron. Memaksa failover diperlukan karena node berada dalam mode commit asinkron.

   ALTER AVAILABILITY GROUP [cluster-ag] FORCE_FAILOVER_ALLOW_DATA_LOSS
   GO
   ALTER AVAILABILITY GROUP [cluster-ag]
   MODIFY REPLICA ON 'CLUSTER-SQL3' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
   GO
   

   Anda dapat melanjutkan pemrosesan; cluster-sql3 sekarang menjadi instance utama.

4. (Opsional) Buat tabel baru di cluster-sql3. Setelah menyinkronkan replika dengan replika utama yang baru, periksa apakah tabel ini direplikasi ke replika.

   USE TestDB
   GO
   CREATE TABLE dbo.TestTable_After_DR (ID INT NOT NULL)
   GO
   

Meskipun cluster-sql3 adalah yang utama pada tahap ini, Anda mungkin perlu kembali ke region asli atau menyiapkan instance sekunder dan instance standby baru untuk membuat ulang arsitektur DR lengkap lagi. Bagian berikutnya akan membahas opsi ini.

(Opsional) Buat ulang arsitektur DR yang benar-benar mereplikasi transaksi

Kasus penggunaan ini mengatasi kegagalan saat semua transaksi direplikasi dari database utama ke database sekunder sebelum database utama gagal. Dalam skenario ideal ini, tidak ada data yang hilang; status sekunder konsisten dengan status utama pada titik kegagalan.

Dalam skenario ini, Anda dapat membuat ulang arsitektur DR lengkap dengan dua cara:

• Mengembalikan ke mode utama asli dan standby asli (jika keduanya tersedia).
• Membuat mode standby dan sekunder baru untuk cluster-sql3 jika layanan utama dan standby yang asli tidak tersedia.

Pendekatan 1: Beralih ke primer awal dan standby

1. Di Cloud Shell, mulai versi utama (lama) dan standby:

   gcloud compute instances start cluster-sql1 --zone us-central1-c --quiet
   gcloud compute instances start cluster-sql2 --zone us-central1-f --quiet
   

2. Di Microsoft SQL Server Management Studio, tambahkan kembali cluster-sql1 dan cluster-sql2 sebagai replika sekunder:

   1. Pada cluster-sql3, tambahkan kedua server dalam mode commit asinkron:

      USE [master]
      GO
      ALTER AVAILABILITY GROUP [cluster-ag]
      MODIFY REPLICA ON 'CLUSTER-SQL1' WITH (FAILOVER_MODE = MANUAL)
      GO
      ALTER AVAILABILITY GROUP [cluster-ag]
      MODIFY REPLICA ON 'CLUSTER-SQL1' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
      GO
      ALTER AVAILABILITY GROUP [cluster-ag]
      MODIFY REPLICA ON 'CLUSTER-SQL2' WITH (FAILOVER_MODE = MANUAL)
      GO
      ALTER AVAILABILITY GROUP [cluster-ag]
      MODIFY REPLICA ON 'CLUSTER-SQL2' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
      GO
      

   2. Pada cluster-sql1, mulai sinkronkan database lagi:

      USE [master]
      GO
      ALTER DATABASE [TestDB] SET HADR RESUME;
      GO
      

   3. Pada cluster-sql2, mulai sinkronkan database lagi:

      USE [master]
      GO
      ALTER DATABASE [TestDB] SET HADR RESUME;
      GO
      

3. Jadikan cluster-sql1 sebagai yang utama lagi:

   1. Pada cluster-sql3, ubah mode ketersediaan cluster-sql1 menjadi commit sinkron. Instance cluster-sql1 menjadi yang utama lagi.

      USE [master]
      GO
      ALTER AVAILABILITY GROUP [cluster-ag]
      MODIFY REPLICA ON 'CLUSTER-SQL1' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
      GO
      

   2. Pada cluster-sql1, ubah cluster-sql1 menjadi yang utama dan dua node lainnya menjadi yang sekunder:

      USE [master]
      GO
      -- Node 1 becomes primary
      ALTER AVAILABILITY GROUP [cluster-ag] FAILOVER;
      GO
      
      -- Node 2 has synchronous commit
      ALTER AVAILABILITY GROUP [cluster-ag]
      MODIFY REPLICA ON 'CLUSTER-SQL2' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
      GO
      
      -- Node 3 has asynchronous commit
      ALTER AVAILABILITY GROUP [cluster-ag]
      MODIFY REPLICA ON 'CLUSTER-SQL3' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
      GO
      

Setelah semua perintah berhasil, cluster-sql1 adalah yang utama, dan node lainnya adalah sekunder, seperti yang ditunjukkan diagram berikut.

Cara 2: Menyiapkan perangkat utama dan standby baru

Anda mungkin tidak dapat memulihkan instance utama dan instance standby yang asli dari kegagalan, atau waktu yang terlalu lama untuk memulihkannya, atau region tidak dapat diakses. Salah satu pendekatannya adalah mempertahankan cluster-sql3 sebagai yang utama, lalu membuat instance standby baru dan instance sekunder baru, seperti yang ditunjukkan dalam diagram berikut.

Gambar 5. Pemulihan dari bencana (disaster recovery) dengan region utama asli R1 yang tidak tersedia.

Penerapan ini mengharuskan Anda melakukan hal berikut:

• Tetap gunakan cluster-sql3 sebagai yang utama di us-east1.

• Tambahkan instance standby baru (cluster-sql4) di zona berbeda di us-east1. Langkah ini menetapkan deployment baru sebagai sangat tersedia.

• Buat instance sekunder baru (cluster-sql5) di region terpisah, misalnya, us-west2. Langkah ini akan menyiapkan deployment baru untuk pemulihan dari bencana. Deployment keseluruhan kini telah selesai. Arsitektur database sepenuhnya mendukung HA dan DR.

(Opsional) Menjalankan penggantian saat transaksi tidak ada

Kegagalan yang kurang ideal terjadi ketika satu atau beberapa transaksi yang dilakukan pada traffic utama tidak direplikasi ke transaksi sekunder pada saat kegagalan (juga dikenal sebagai kegagalan fatal). Dalam failover, semua transaksi yang di-commit yang tidak direplikasi akan hilang.

Untuk menguji langkah-langkah failover untuk skenario ini, Anda harus membuat kegagalan yang sulit. Pendekatan terbaik untuk menghasilkan kegagalan yang sulit adalah sebagai berikut:

• Ubah jaringan sehingga tidak ada konektivitas antara instance utama dan sekunder.
• Ubah yang utama dengan cara tertentu—misalnya, tambahkan tabel atau sisipkan beberapa data.
• Melangkahlah melalui proses failover seperti yang diuraikan sebelumnya sehingga sekunder menjadi primer baru.

Langkah-langkah untuk proses failover identik dengan skenario ideal, kecuali tabel yang ditambahkan ke utama setelah konektivitas jaringan terganggu tidak terlihat di sekunder.

Satu-satunya opsi Anda untuk menangani kegagalan yang sulit adalah menghapus replika (cluster-sql1 dan cluster-sql2) dari grup ketersediaan, lalu menyinkronkan replika lagi. Sinkronisasi mengubah statusnya agar cocok dengan sekunder. Setiap transaksi yang tidak direplikasi sebelum kegagalan akan hilang.

Untuk menambahkan cluster-sql1 sebagai instance sekunder, Anda dapat mengikuti langkah yang sama untuk menambahkan cluster-sql3 sebelumnya (lihat Menambahkan instance sekunder ke cluster failover sebelumnya) dengan perbedaan berikut: cluster-sql3 sekarang menjadi instance utama, bukan cluster-sql1. Anda harus mengganti instance cluster-sql3 dengan nama server yang Anda tambahkan ke grup ketersediaan. Jika menggunakan kembali VM yang sama (cluster-sql1 dan cluster-sql2), Anda tidak perlu menambahkan server ke Cluster Failover Windows Server; cukup tambahkan instance SQL Server kembali ke grup ketersediaan.

Pada tahap ini, cluster-sql3 adalah yang utama, serta cluster-sql1 dan cluster-sql2 adalah sekunder. Sekarang Anda dapat kembali ke cluster-sql1, untuk membuat cluster-sql2 menjadi standby, dan menjadikan cluster-sql3 sebagai sekunder. Sistem kini memiliki status yang sama seperti sebelum kegagalan.

Failover otomatis

Gagal secara otomatis ke instance sekunder sebagai instance utama dapat menimbulkan masalah. Setelah primer asli tersedia lagi, situasi otak terpisah dapat terjadi jika beberapa klien mengakses sekunder, sementara yang lain menulis ke primer yang dipulihkan. Dalam hal ini, status primer dan sekunder mungkin diupdate secara paralel, dan statusnya berbeda. Untuk menghindari situasi tersebut, tutorial ini memberikan petunjuk untuk failover manual saat Anda memutuskan apakah akan menggagalkan (atau kapan) akan gagal.

Jika menerapkan failover otomatis, Anda harus memastikan bahwa hanya satu instance yang dikonfigurasi yang merupakan instance utama dan dapat diubah. Setiap instance standby atau sekunder tidak boleh memberikan akses tulis ke klien apa pun (kecuali primer untuk replikasi status). Selain itu, Anda harus menghindari rantai failover berikutnya dengan cepat dalam waktu singkat. Misalnya, failover setiap lima menit bukanlah strategi pemulihan dari bencana (disaster recovery) yang dapat diandalkan. Untuk proses failover otomatis, Anda dapat membangun pengamanan dari skenario bermasalah seperti ini, dan bahkan melibatkan administrator database untuk keputusan yang kompleks, jika diperlukan.

Arsitektur deployment alternatif

Tutorial ini menyiapkan arsitektur pemulihan dari bencana dengan instance sekunder yang menjadi instance utama dalam failover, seperti yang ditunjukkan dalam diagram berikut.

Gambar 6. Arsitektur pemulihan dari bencana standar menggunakan Microsoft SQL Server.

Artinya, jika terjadi failover, deployment yang dihasilkan memiliki satu instance hingga penggantian dapat dilakukan, atau hingga Anda mengonfigurasi mode standby (untuk HA) dan sekunder (untuk DR).

Arsitektur deployment alternatif adalah mengonfigurasi dua instance sekunder. Kedua instance adalah replika dari instance utama. Jika terjadi failover, Anda dapat mengonfigurasi ulang salah satu instance sekunder sebagai standby. Diagram berikut menunjukkan arsitektur deployment sebelum dan sesudah failover.

Gambar 7. Arsitektur pemulihan bencana standar dengan dua instance sekunder.

Gambar 8. Arsitektur pemulihan bencana standar dengan dua {i>instance<i} sekunder setelah failover.

Meskipun Anda tetap harus menjadikan salah satu dari dua instance sekunder sebagai standby (Gambar 8), proses ini jauh lebih cepat daripada membuat dan mengonfigurasi standby baru dari awal.

Anda juga dapat mengatasi DR dengan penyiapan yang serupa dengan arsitektur penggunaan dua instance sekunder ini. Selain memiliki dua instance sekunder di region kedua (Gambar 7), Anda dapat men-deploy dua instance sekunder lain di region ketiga. Penyiapan ini memungkinkan Anda membuat arsitektur deployment yang mendukung HA dan DR secara efisien setelah terjadi kegagalan region utama.

Pembersihan

Agar tidak menimbulkan tagihan ke akun Google Cloud Anda untuk resource yang digunakan dalam 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.
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

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