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

---

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 saat database utama gagal atau tidak tersedia.

Database utama dapat gagal jika region tempatnya berada gagal atau menjadi tidak dapat diakses. Meskipun region tersedia dan beroperasi secara normal, database utama dapat gagal karena error sistem. Dalam hal ini, disaster recovery adalah proses menyediakan database sekunder kepada klien untuk pemrosesan lanjutan.

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

Tujuan

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

Biaya

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

• Compute Engine
• SQL Server VMs

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 dibuat:

1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   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

2. Make sure that billing is enabled for your Google Cloud project.

3. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

Memahami pemulihan dari bencana (disaster recovery)

Di Google Cloud, pemulihan dari bencana (DR) berfokus pada penyediaan keberlangsungan pemrosesan, khususnya saat region gagal atau tidak dapat diakses. Untuk sistem seperti sistem pengelolaan database, Anda menerapkan DR dengan men-deploy sistem di setidaknya dua region. Dengan penyiapan ini, sistem akan terus beroperasi jika satu region tidak tersedia.

Pemulihan dari bencana (disaster recovery) sistem database

Proses menyediakan database sekunder saat instance database utama gagal disebut pemulihan dari 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 pada saat database utama tidak tersedia, atau database sekunder hanya melewatkan 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 zonanya 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 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).

Pada diagram sebelumnya, arsitektur menunjukkan grup ketersediaan. Grup ketersediaan, jika digunakan dengan pemroses, memberikan string koneksi yang sama ke klien jika klien ditayangkan oleh hal berikut:

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

Dalam 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 memiliki ketersediaan tinggi; pemadaman layanan satu zona mungkin diperlukan untuk memulai proses DR.

Proses pemulihan dari bencana (disaster recovery) dasar

Proses DR dimulai saat region 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 mengurangi 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, menjadi tidak 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 dibuat sebagai instance utama baru.
4. Klien melanjutkan pemrosesan di database utama yang baru dan mengakses instance utama di R2.

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

Proses pemulihan dari bencana (disaster recovery) lengkap

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.

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

Arsitektur DR database yang lengkap ini berfungsi sebagai berikut:

1. Region pertama (R1), yang menjalankan instance database utama, menjadi tidak 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 dibuat sebagai 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 dibuat dan dimulai. Instance sekunder ini terhubung secara asinkron ke instance utama baru di R2. Pada tahap ini, arsitektur pemulihan dari bencana yang asli dibuat ulang dan dapat dioperasikan.

Penggantian ke region yang dipulihkan

Setelah region pertama (R1) kembali 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 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
• SQL Server 2022 Enterprise Edition

Tutorial ini menggunakan fitur Grup Ketersediaan AlwaysOn di SQL Server.

Jika Anda tidak memerlukan database utama Microsoft SQL Server dengan ketersediaan tinggi (HA), dan satu instance database sudah cukup sebagai database 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 2022 Standard Edition

SQL Server versi 2016, 2017, 2019, dan 2022 memiliki Microsoft SQL Server Management Studio yang diinstal dalam image; Anda tidak perlu menginstalnya secara terpisah. Namun, dalam lingkungan produksi, sebaiknya Anda menginstal satu instance Microsoft SQL Server Management Studio di VM terpisah di setiap region. Jika menyiapkan lingkungan HA, Anda harus menginstal Microsoft SQL Server Management Studio satu kali untuk setiap zona guna memastikannya tetap tersedia jika zona lain tidak tersedia.

Menyiapkan Microsoft SQL Server untuk DR multi-regional

Bagian ini menggunakan image berikut untuk Microsoft SQL Server:

• sql-ent-2016-win-2016 untuk Microsoft SQL Server 2016 Enterprise Edition
• sql-ent-2017-win-2016 untuk Microsoft SQL Server 2017 Enterprise Edition
• sql-ent-2019-win-2019 untuk Microsoft SQL Server 2019 Edisi Enterprise
• sql-ent-2022-win-2022 untuk Microsoft SQL Server 2022 Edisi Enterprise

Untuk daftar lengkap image, lihat Gambar.

Menyiapkan cluster ketersediaan tinggi dengan dua instance

Untuk menyiapkan arsitektur DR database multi-regional untuk SQL Server, Anda harus membuat cluster ketersediaan tinggi (HA) dua instance di region terlebih dahulu. Satu instance berfungsi sebagai instance utama, dan instance lainnya berfungsi sebagai instance 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:

• Jika mengikuti langkah-langkah dalam Mengonfigurasi grup ketersediaan AlwaysOn SQL Server, Anda akan membuat dua instance SQL Server di region yang sama (us-central1). Anda akan men-deploy instance SQL Server utama (node-1) di us-central1-a, dan instance standby (node-2) di us-central1-b.

• Meskipun Anda menerapkan arsitektur dalam Gambar 4 untuk tutorial ini, sebaiknya siapkan pengontrol domain di lebih dari satu zona. Pendekatan ini memastikan bahwa Anda membuat arsitektur database yang mendukung HA dan DR. Misalnya, jika pemadaman layanan terjadi di satu zona, zona tersebut tidak akan menjadi titik kegagalan tunggal untuk arsitektur yang di-deploy.

Gambar 4. Arsitektur disaster recovery standar yang diterapkan dalam tutorial ini.

Menambahkan instance sekunder untuk pemulihan dari bencana (disaster recovery)

Selanjutnya, Anda menyiapkan instance SQL Server ketiga (instance sekunder yang bernama node-3), dan mengonfigurasi jaringan sebagai berikut:

1. Buat skrip spesialisasi untuk node Cluster Windows Server Failover. Skrip ini menginstal fitur Windows yang diperlukan serta membuat aturan firewall untuk WSFC dan SQL Server. Langkah ini juga akan memformat disk data dan membuat folder data dan log untuk SQL Server:

   cat << "EOF" > specialize-node.ps1
   
   $ErrorActionPreference = "stop"
   
   # Install required Windows features
   Install-WindowsFeature Failover-Clustering -IncludeManagementTools
   Install-WindowsFeature RSAT-AD-PowerShell
   
   # Open firewall for WSFC
   netsh advfirewall firewall add rule name="Allow SQL Server health check" dir=in action=allow protocol=TCP localport=59997
   
   # Open firewall for SQL Server
   netsh advfirewall firewall add rule name="Allow SQL Server" dir=in action=allow protocol=TCP localport=1433
   
   # Open firewall for SQL Server replication
   netsh advfirewall firewall add rule name="Allow SQL Server replication" dir=in action=allow protocol=TCP localport=5022
   
   # Format data disk
   Get-Disk |
    Where partitionstyle -eq 'RAW' |
    Initialize-Disk -PartitionStyle MBR -PassThru |
    New-Partition -AssignDriveLetter -UseMaximumSize |
    Format-Volume -FileSystem NTFS -NewFileSystemLabel 'Data' -Confirm:$false
   
   # Create data and log folders for SQL Server
   md d:\Data
   md d:\Logs
   EOF
   

2. Lakukan inisialisasi variabel berikut:

   VPC_NAME=VPC_NAME
   SUBNET_NAME=SUBNET_NAME
   REGION=us-east1
   PD_SIZE=200
   MACHINE_TYPE=n2-standard-8
   

   Dengan keterangan:

   • VPC_NAME: nama VPC Anda
   • SUBNET_NAME: nama subnet Anda untuk region us-east1

3. Buat instance SQL Server:

   gcloud compute instances create node-3 \
   --zone $REGION-b \
   --machine-type $MACHINE_TYPE \
   --subnet $SUBNET_NAME \
   --image-family sql-ent-2022-win-2022 \
   --image-project windows-sql-cloud \
   --tags wsfc,wsfc-node \
   --boot-disk-size 50 \
   --boot-disk-type pd-ssd \
   --boot-disk-device-name "node-3" \
   --create-disk=name=node-3-datadisk,size=$PD_SIZE,type=pd-ssd,auto-delete=no \
   --metadata enable-wsfc=true \
   --metadata-from-file=sysprep-specialize-script-ps1=specialize-node.ps1
   

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 node-3, pilih menu drop-down Setel sandi Windows.

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

5. Klik RDP untuk terhubung ke instance node-3.

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

7. Tambahkan instance ke domain Windows:

   1. Klik kanan tombol Start (atau tekan Win+X), lalu klik Windows PowerShell (Admin).

   2. Konfirmasi perintah elevasi dengan mengklik Yes.

   3. Gabungkan komputer ke domain Active Directory Anda, lalu mulai ulang:

      Add-Computer -Domain DOMAIN -Restart
      

      Ganti DOMAIN dengan nama DNS domain Active Directory Anda.

      Tunggu sekitar 1 menit sampai proses mulai ulang selesai.

Menambahkan instance sekunder ke cluster failover

Selanjutnya, Anda menambahkan instance sekunder (node-3) ke cluster failover Windows:

1. Hubungkan ke instance node-1 atau node-2 menggunakan RDP, dan login sebagai pengguna Administrator.

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

   $node3 = "node-3"
   $nameWSFC = "SQLSRV_CLUSTER" # Name of cluster 
   

   Ganti SQLSRV_CLUSTER dengan nama cluster SQL Server.

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 proses ini dapat berhenti merespons dan tidak kembali secara otomatis, tekan Enter sesekali.

4. Di node, aktifkan fitur ketersediaan tinggi AlwaysOn:

   Enable-SqlAlwaysOn -ServerInstance $node3 -Force
   

Node kini menjadi bagian dari cluster failover.

Menambahkan instance sekunder ke grup ketersediaan yang ada

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

1. Hubungkan ke node-3 menggunakan Desktop Jarak Jauh. Login dengan akun pengguna domain Anda.

2. Buka SQL Server Configuration Manager.

3. Di panel navigasi, pilih SQL Server Services

4. Di daftar layanan, klik kanan SQL Server (MSSQLSERVER) lalu pilih Properties.

5. Di bagian Log on as, ubah akun:

   • Account name: DOMAIN\sql_server dengan DOMAIN adalah nama NetBIOS domain Active Directory Anda.
   • Sandi: Masukkan sandi yang Anda pilih sebelumnya untuk akun domain sql_server.

6. Klik Oke.

7. Saat diminta untuk memulai ulang SQL Server, pilih Yes.

8. Di salah satu dari tiga node instance node-1, node-2, atau node-3, buka Microsoft SQL Server Management Studio dan hubungkan ke instance utama—node-1.

   1. Buka Penjelajah Objek.
   2. Pilih menu drop-down Connect.
   3. Pilih Mesin Database.
   4. Dari menu drop-down Nama Server, pilih node-1. Jika cluster tidak tercantum, masukkan cluster tersebut di kolom.

9. Click Kueri Baru.

   Catatan: Langkah 9 dan 10 tidak diperlukan jika nama jaringan terdistribusi digunakan untuk menyiapkan grup ketersediaan AlwaysOn.

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

    ALTER AVAILABILITY GROUP [bookshelf-ag] MODIFY LISTENER 'bookshelf' (ADD IP ('LOAD_BALANCER_IP_ADDRESS', '255.255.255.0'))
    

    Ganti LOAD_BALANCER_IP_ADDRESS dengan Alamat IP load balancer di region us-east1.

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

12. Klik kanan grup ketersediaan yang bernama bookshelf-ag, lalu pilih Tambahkan Replika.

13. Di halaman Pengantar, klik node AlwaysOn High Availability, lalu klik node Availability Groups.

14. Di halaman Connect to Replicas(Hubungkan ke Replika), klik Connect untuk terhubung ke replika sekunder yang ada node-2.

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

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

    Karena tidak ada pemroses, halaman Validasi akan menampilkan peringatan, yang dapat Anda abaikan.

17. Selesaikan langkah-langkah wizard.

Mode failover untuk node-1 dan node-2 bersifat otomatis, sedangkan untuk node-3 bersifat manual. Perbedaan ini adalah salah satu cara untuk membedakan ketersediaan tinggi dari pemulihan dari bencana (disaster recovery).

Grup ketersediaan kini siap. Anda mengonfigurasi dua node untuk ketersediaan tinggi dan node ketiga untuk pemulihan dari bencana.

Menyimulasikan pemulihan dari bencana (disaster recovery)

Di bagian ini, Anda akan menguji arsitektur disaster recovery untuk tutorial ini dan mempertimbangkan penerapan DR opsional.

Menyimulasikan pemadaman layanan dan menjalankan failover DR

1. Menyimulasikan kegagalan atau pemadaman layanan di region utama:

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

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

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

   3. Di Cloud Shell, matikan kedua server di region utama us-central1:

      gcloud compute instances stop node-2 --zone us-central1-b --quiet
      gcloud compute instances stop node-1 --zone us-central1-a --quiet
      

   Catatan: Cara alternatif untuk membuat kegagalan adalah dengan menghentikan VM yang menjalankan node-1 dan node-2. Pendekatan ini menyimulasikan kegagalan berat, bukan shutdown instance biasa.

2. Di Microsoft SQL Server Management Studio pada node-3, hubungkan ke node-3.

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

   ALTER AVAILABILITY GROUP [bookshelf-ag] FORCE_FAILOVER_ALLOW_DATA_LOSS
   GO
   ALTER AVAILABILITY GROUP [bookshelf-ag]
   MODIFY REPLICA ON 'node-3' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
   GO
   

   Anda dapat melanjutkan pemrosesan; node-3 kini menjadi instance utama.

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

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

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

(Opsional) Buat ulang arsitektur DR yang sepenuhnya mereplikasi transaksi

Kasus penggunaan ini menangani 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 utama pada titik kegagalan.

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

• Kembali ke utama asli dan standby asli (jika tersedia).
• Buat standby dan sekunder baru untuk node-3 jika utama dan standby asli tidak tersedia.

Pendekatan 1: Kembali ke utama dan standby asli

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

   gcloud compute instances start node-1 --zone us-central1-a --quiet
   gcloud compute instances start node-2 --zone us-central1-b --quiet
   

2. Di Microsoft SQL Server Management Studio, tambahkan kembali node-1 dan node-2 sebagai replika sekunder:

   1. Di node-3, tambahkan dua server dalam mode commit asinkron:

      USE [master]
      GO
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-1' WITH (FAILOVER_MODE = MANUAL)
      GO
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-1' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
      GO
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-2' WITH (FAILOVER_MODE = MANUAL)
      GO
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-2' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
      GO
      

   2. Di node-1, mulai sinkronkan database lagi:

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

   3. Di node-2, mulai sinkronkan database lagi:

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

3. Jadikan node-1 sebagai utama lagi:

   1. Di node-3, ubah mode ketersediaan node-1 menjadi commit sinkron. Instance node-1 menjadi instance utama lagi.

      USE [master]
      GO
      ALTER AVAILABILITY GROUP [bookshelf-ag]
      MODIFY REPLICA ON 'node-1' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
      GO
      

   2. Di node-1, ubah node-1 menjadi node utama dan dua node lainnya menjadi node sekunder:

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

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

Pendekatan 2: Menyiapkan instance utama dan standby baru

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

Gambar 5. Disaster recovery dengan region utama asli R1 yang tidak tersedia.

Penerapan ini mengharuskan Anda melakukan hal berikut:

• Pertahankan node-3 sebagai utama di us-east1.

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

• Buat instance sekunder baru (node-5) di region terpisah, misalnya, us-west2. Langkah ini menyiapkan deployment baru untuk pemulihan bencana. Deployment secara keseluruhan kini telah selesai. Arsitektur database secara penuh mendukung HA dan DR.

(Opsional) Menjalankan penggantian saat transaksi tidak ada

Kegagalan yang kurang ideal adalah saat satu atau beberapa transaksi yang di-commit di utama tidak direplikasi ke sekunder pada titik kegagalan (juga dikenal sebagai kegagalan berat). Dalam failover, semua transaksi yang di-commit dan 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 primary dengan cara tertentu—misalnya, tambahkan tabel atau masukkan beberapa data.
• Ikuti 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 primer setelah konektivitas jaringan terganggu tidak terlihat di sekunder.

Satu-satunya opsi Anda untuk menangani kegagalan yang sulit adalah menghapus replika (node-1 dan node-2) 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 node-1 sebagai instance sekunder, Anda dapat mengikuti langkah-langkah yang sama untuk menambahkan node-3 sebelumnya (lihat Menambahkan instance sekunder ke cluster failover sebelumnya) dengan perbedaan berikut: node-3 kini menjadi instance utama, bukan node-1. Anda perlu mengganti instance node-3 dengan nama server yang ditambahkan ke grup ketersediaan. Jika menggunakan kembali VM yang sama (node-1 dan node-2), Anda tidak perlu menambahkan server ke Windows Server Failover Cluster; cukup tambahkan instance SQL Server kembali ke grup ketersediaan.

Pada tahap ini, node-3 adalah utama, dan node-1 serta node-2 adalah sekunder. Sekarang Anda dapat kembali ke node-1, menjadikan node-2 sebagai standby, dan menjadikan node-3 sebagai sekunder. Sistem kini memiliki status yang sama dengan sebelum kegagalan.

Failover otomatis

Failover otomatis ke instance sekunder sebagai instance utama dapat menimbulkan masalah. Setelah instance utama asli tersedia kembali, situasi split-brain dapat terjadi jika beberapa klien mengakses instance sekunder, sementara yang lain menulis ke instance utama yang dipulihkan. Dalam hal ini, primary dan secondary mungkin diperbarui secara paralel, dan statusnya berbeda. Untuk menghindari situasi ini, tutorial ini memberikan petunjuk untuk failover manual yang memungkinkan Anda memutuskan apakah (atau kapan) akan melakukan failover.

Jika menerapkan failover otomatis, Anda harus memastikan bahwa hanya satu dari instance yang dikonfigurasi yang merupakan instance utama dan dapat diubah. Setiap instance cadangan atau sekunder tidak boleh memberikan akses tulis ke klien mana pun (kecuali utama untuk replikasi status). Selain itu, Anda harus menghindari rantai failover berikutnya yang cepat dalam waktu singkat. Misalnya, failover setiap lima menit tidak akan menjadi strategi disaster recovery yang andal. 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 disaster recovery 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 akan memiliki satu instance hingga fallback dapat dilakukan, atau hingga Anda mengonfigurasi standby (untuk HA) dan sekunder (untuk DR).

Arsitektur deployment alternatif adalah mengonfigurasi dua instance sekunder. Kedua instance tersebut 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 disaster recovery standar dengan dua instance sekunder.

Gambar 8. Arsitektur disaster recovery standar dengan dua instance 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 analog dengan arsitektur ini menggunakan dua instance sekunder. 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 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. In the Google Cloud console, go to the Manage resources page.

   Go to Manage resources

2. In the project list, select the project that you want to delete, and then click Delete.
3. In the dialog, type the project ID, and then click Shut down to delete the project.

Langkah berikutnya

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