Halaman ini diterjemahkan oleh Cloud Translation API.

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 di mana {i>database<i} utama gagal atau menjadi tidak tersedia.

Database utama dapat mengalami kegagalan jika regionnya berada gagal atau menjadi tidak dapat diakses. Bahkan jika suatu wilayah tersedia dan beroperasi secara normal, {i>database<i} dapat gagal karena terjadinya {i>error<i} pada sistem. Dalam kasus ini, pemulihan dari bencana adalah proses pembuatan {i>database<i} sekunder tersedia bagi klien untuk diproses.

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

Tujuan

Deploy lingkungan pemulihan dari bencana multi-regional di Google Cloud dengan ketersediaan AlwaysOn Availability Microsoft SQL Server Grup.
Menyimulasikan peristiwa bencana dan melakukan pemulihan dari bencana sepenuhnya untuk memvalidasi konfigurasi pemulihan dari bencana.

Biaya

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

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 yang baru, atau pilih project yang sudah Anda buat:

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
Pastikan penagihan telah diaktifkan untuk project Google Cloud Anda.
Di konsol Google Cloud, aktifkan Cloud Shell.

Aktifkan Cloud Shell

Memahami pemulihan dari bencana (disaster recovery)

Di Google Cloud, pemulihan dari bencana (DR) adalah tentang menyediakan kontinuitas pemrosesan data, terutama saat region gagal atau tidak dapat diakses. Untuk sistem seperti sistem manajemen database, Anda menerapkan DR dengan men-deploy sistem di minimal dua region. Dengan pengaturan ini, sistem akan terus beroperasi jika ada region menjadi tidak tersedia.

Pemulihan dari bencana (disaster recovery) sistem database

Proses pembuatan {i>database<i} sekunder tersedia saat {i>database<i} utama Kegagalan instance disebut pemulihan database dari bencana (atau DR database). Untuk diskusi terperinci tentang konsep ini, lihat Pemulihan dari bencana untuk Microsoft SQL Server. Idealnya, keadaan {i>database<i} sekunder konsisten dengan saat database utama menjadi tidak tersedia, atau database sekunder kehilangan satu set kecil transaksi terbaru dari {i>database<i} utama.

Arsitektur pemulihan dari bencana (disaster recovery)

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

Instance utama dan standby terletak di dua zona dalam region R1, dan instance sekunder terletak di region R2.

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

Arsitektur ini berfungsi sebagai berikut:

Dua instance Microsoft SQL Server (instance utama dan instance standby) instance) berada di region yang sama (R1), tetapi berbeda zona (zona A dan B). Dua {i>instance<i} dalam R1 mengoordinasikan keadaannya dengan menggunakan mode commit sinkron. Mode sinkron digunakan karena mendukung ketersediaan dan mempertahankan status data yang konsisten.
Salah satu instance Microsoft SQL Server (pemulihan sekunder atau pemulihan dari bencana instance) terletak di region kedua (R2). Untuk DR, sekunder {i>instance <i}di R2 menyinkronkan dengan {i>instance<i} utama di R1 dengan menggunakan mode commit asinkron. Mode asinkron digunakan karena performa (tidak memperlambat pemrosesan commit di instance).

Pada diagram sebelumnya, arsitektur ini menampilkan grup ketersediaan. Tujuan grup ketersediaan, jika digunakan bersama pemroses, menyediakan string koneksi yang sama jika klien dilayani oleh berikut ini:

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

Dalam varian arsitektur di atas, Anda men-deploy dua instance yang di region pertama (R1) ke dalam zona yang sama. Pendekatan ini mungkin meningkatkan performa, tetapi ketersediaannya tidak tinggi; mungkin diperlukan pemadaman layanan satu zona untuk memulai proses DR.

Proses pemulihan dari bencana (disaster recovery) dasar

Proses DR dimulai saat region menjadi tidak tersedia dan region utama database gagal melanjutkan pemrosesan di region operasional lain. DR menentukan langkah-langkah operasional yang harus diambil, baik secara manual secara otomatis, untuk memitigasi kegagalan region dan membangun jaringan di region yang tersedia.

Proses DR database dasar terdiri dari langkah-langkah berikut:

Region pertama (R1), yang menjalankan instance database utama, menjadi tidak tersedia.
Tim operasi mengenali dan secara resmi mengonfirmasi bencana, dan memutuskan apakah failover diperlukan.
Jika failover diperlukan, instance database sekunder di instance region (R2) dijadikan instance utama baru.
Klien melanjutkan pemrosesan pada {i>database<i} utama yang baru dan mengakses instance utama di R2.

Meskipun proses dasar ini menetapkan kembali sebuah {i>database<i} utama yang berfungsi, tidak membentuk arsitektur DR yang lengkap, di mana primer baru memiliki standby, dan instance database sekunder.

Proses pemulihan dari bencana (disaster recovery) lengkap

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

Dalam arsitektur DR database yang lengkap, instance sekunder di region R2 menjadi instance utama, dan instance sekunder baru dibuat di region R3.

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

Arsitektur DR database lengkap ini berfungsi sebagai berikut:

Region pertama (R1), yang menjalankan instance database utama, menjadi tidak tersedia.
Tim operasi mengenali dan secara resmi mengakui bencana dan memutuskan apakah failover diperlukan..
Jika failover diperlukan, instance database sekunder di instance region (R2) dijadikan instance utama.
Instance sekunder lainnya, instance standby baru, dibuat dan dimulai di R2 dan ditambahkan ke {i>instance<i} utama. Instance standby sedang zona yang berbeda dari instance utama. Database utama sekarang terdiri dari dua instance (utama dan standby) yang sangat tersedia.
Di region ketiga (R3), instance database sekunder (standby) baru dibuat dan dimulai. Instance sekunder ini terhubung secara asinkron instance utama baru di R2. Pada tahap ini, arsitektur pemulihan dari bencana dibuat ulang dan beroperasi.

Penggantian ke region yang dipulihkan

Setelah region pertama (R1) dikembalikan ke internet, region baru tersebut dapat menghosting {i>database<i} sekunder. Jika R1 segera tersedia, Anda dapat mengimplementasikan langkah 5 dalam proses pemulihan lengkap di R1 alih-alih R3 (region ketiga). Di beberapa dalam hal ini, region ketiga tidak diperlukan.

Diagram berikut menunjukkan arsitektur jika R1 tersedia tepat waktu.

Jika region R1 dipulihkan tepat waktu, instance sekunder akan dibuat di region R1.

Gambar 3. Pemulihan dari bencana setelah region R1 yang gagal tersedia untuk mencoba lagi perintah.

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 Microsoft SQL Server utama (HA) yang sangat tersedia dan satu instance database sudah cukup sebagai instance utama, Anda dapat menggunakan versi SQL Server berikut ini:

SQL Server 2016 Standard Edition
SQL Server 2017 Standard Edition
SQL Server 2019 Standard Edition
SQL Server 2022 Edisi Standar

Versi SQL Server 2016, 2017, 2019, dan 2022 memiliki Microsoft SQL Server Management Studio yang diinstal di gambar; Anda tidak perlu menginstalnya secara terpisah. Namun, dalam lingkungan produksi, sebaiknya Anda menginstal satu instance Microsoft SQL Server Management Studio di VM terpisah di masing-masing teritorial Anda. Jika Anda menyiapkan lingkungan HA, Anda harus menginstal Microsoft SQL Server Management Studio sekali untuk setiap zona guna memastikan bahwa zona tersebut tetap tersedia jika zona lain menjadi tidak tersedia.

Menyiapkan Microsoft SQL Server untuk DR multi-regional

Bagian ini menggunakan gambar 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 Enterprise Edition
sql-ent-2022-win-2022 untuk Microsoft SQL Server 2022 Enterprise Edition

Untuk mengetahui daftar lengkap gambar, lihat Gambar.

Menyiapkan cluster ketersediaan tinggi dua instance

Untuk menyiapkan arsitektur DR database multi-regional untuk SQL Server, Anda perlu membuat cluster ketersediaan tinggi (HA) dua instance di sebuah 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:

Jika Anda mengikuti langkah-langkah dalam Mengonfigurasi grup ketersediaan SQL Server AlwaysOn, 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 di Gambar 4 untuk tutorial ini, sebaiknya untuk menyiapkan {i>domain controller<i} di lebih dari satu zona. Pendekatan ini memastikan bahwa Anda membuat arsitektur database yang mendukung HA dan DR. Sebagai misalnya, jika pemadaman terjadi di satu zona, zona tersebut tidak menjadi titik kegagalan untuk arsitektur yang di-deploy.

Instance utama dan standby dalam mode sinkron berada di zona yang berbeda di satu region, dan instance sekunder dalam mode asinkron berada di region lain.

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

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:

Membuat skrip spesialisasi untuk node Cluster Windows Server Failover. Skrip menginstal fitur Windows yang diperlukan dan membuat aturan firewall untuk WSFC dan SQL Server. {i>Metadata<i} juga memformat {i> disk<i} 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

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

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

Setel 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. Setel nama pengguna dan sandi. Catat untuk digunakan nanti.
Klik RDP untuk terhubung ke instance node-3.
Masukkan nama pengguna dan sandi dari langkah sebelumnya, lalu klik OK.
Tambahkan instance ke domain Windows:
1. Klik kanan tombol Start (atau tekan Win+X) dan klik Windows PowerShell (Admin).
2. Konfirmasi petunjuk ketinggian dengan mengklik Ya.
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 failover Windows :

Hubungkan ke instance node-1 atau node-2 menggunakan RDP, dan masuk sebagai pengguna Administrator.
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.
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 tersebut dapat menghentikan merespons dan tidak kembali secara otomatis, sesekali tekan Enter.
Di node, aktifkan fitur ketersediaan tinggi Selalu Aktif:
```
Enable-SqlAlwaysOn -ServerInstance $node3 -Force
```

Node sekarang 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:

Hubungkan ke node-3 menggunakan Desktop Jarak Jauh. Login dengan akun pengguna domain Anda.
Buka SQL Server Configuration Manager.
Di panel navigasi, pilih SQL Server Services
Di daftar layanan, klik kanan SQL Server (MSSQLSERVER) lalu pilih Properties.
Di bagian Log on as, ubah akun:
- Account name: DOMAIN\sql_server dengan DOMAIN adalah nama NetBIOS domain Active Directory Anda.
- Password: Masukkan sandi yang telah Anda pilih sebelumnya untuk akun domain sql_server.
Klik Oke.
Saat diminta untuk memulai ulang SQL Server, pilih Yes.
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 Hubungkan.
3. Pilih Mesin Database.
4. Dari menu drop-down Nama Server, pilih node-1. Jika cluster tidak tercantum, masukkan cluster tersebut dalam kolom.
Click Kueri Baru.

Catatan: Langkah 9 dan 10 tidak diperlukan jika nama jaringan terdistribusi digunakan untuk menyiapkan grup ketersediaan AlwaysOn.
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.
Di Penjelajah Objek, luaskan node AlwaysOn High Availability, lalu luaskan node Availability Groups (Grup Ketersediaan).
Klik kanan grup ketersediaan yang bernama bookshelf-ag, lalu pilih Tambahkan Replika.
Di halaman Introduction, klik AlwaysOn High Availability node, lalu klik node Availability Groups.
Di halaman Connect to Replicas(Hubungkan ke Replika), klik Connect untuk terhubung ke replika sekunder yang ada node-2.
Di halaman Specify Replicas(Tentukan Replika), klik Add Replica(Tambahkan Replika), lalu tambahkan node baru node-3. Jangan pilih Failover Otomatis karena failover otomatis menyebabkan commit sinkron. Konfigurasi seperti ini melintasi batas wilayah, yang tidak kami rekomendasikan.
Di halaman Select Data Synchronization(Pilih Sinkronisasi Data), pilih Automatic seeding(Penyebaran otomatis).

Karena tidak ada pemroses, halaman Validasi akan menghasilkan peringatan, yang dapat Anda abaikan.
Selesaikan langkah-langkah wizard.

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

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

Menyimulasikan pemulihan dari bencana (disaster recovery)

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

Simulasikan pemadaman dan jalankan failover DR

Simulasikan 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 jalankan node-1 dan node-2. Pendekatan ini menyimulasikan mengalami kegagalan, bukan penonaktifan instance biasa.
Di Microsoft SQL Server Management Studio di node-3, hubungkan ke node-3.
Jalankan failover, dan tetapkan mode ketersediaan ke commit sinkron. Pemaksaan 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 sekarang menjadi instance utama.
(Opsional) Buat tabel baru di node-3. Setelah menyinkronkan replika dengan yang utama baru, periksa apakah direplikasi ke replika.
```
USE bookshelf
GO
CREATE TABLE dbo.TestTable_After_DR (ID INT NOT NULL)
GO
```

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

(Opsional) Buat ulang arsitektur DR yang sepenuhnya mereplikasi transaksi

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

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

Beralih kembali ke mode utama awal dan mode standby awal (jika setelan yang tersedia).
Buat standby dan sekunder baru untuk node-3 jika mode utama dan standby asli tidak tersedia.

Pendekatan 1: Beralih kembali ke utama dan standby awal

Di Cloud Shell, mulai instance utama (lama) yang asli dan standby:

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

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

Pada node-3, tambahkan kedua server tersebut 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

Pada node-1, mulai sinkronkan database lagi:

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

Pada node-2, mulai sinkronkan database lagi:

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

Jadikan node-1 sebagai utama lagi:

Di node-3, ubah mode ketersediaan node-1 ke commit sinkron. Instance node-1 menjadi domain primer kembali.

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

Di node-1, ubah node-1 menjadi yang utama dan dua {i>node<i} lainnya untuk menjadi 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 menjadi node utama, dan node lainnya bersifat sekunder, seperti yang ditampilkan dalam diagram berikut.

Penjelajah Objek menampilkan grup ketersediaan.

Pendekatan 2: Menyiapkan server utama dan standby baru

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

Instance standby dibuat di zona terpisah tetapi di region yang sama dengan instance utama, dan instance sekunder dibuat di region terpisah.

Gambar 5. Pemulihan dari bencana dengan region primer R1 asli yang tidak tersedia.

Penerapan ini mengharuskan Anda melakukan hal berikut:

Biarkan node-3 sebagai yang utama di us-east1.
Tambahkan instance standby baru (node-4) di zona lain di us-east1. Langkah ini akan menetapkan deployment baru sebagai sangat tersedia.
Buat instance sekunder baru (node-5) di region terpisah. misalnya us-west2. Langkah ini menyiapkan deployment baru untuk penanganan bencana pemulihan data. Deployment keseluruhan kini telah selesai. {i>Database<i} mendukung penuh HA dan DR.

(Opsional) Menjalankan penggantian saat transaksi tidak ada

Kegagalan yang kurang ideal terjadi saat satu atau beberapa transaksi dilakukan di primer tidak direplikasi ke sekunder pada titik kegagalan (juga diketahui sebagai kegagalan berat). Dalam failover, semua transaksi yang di-commit yang tidak direplikasi, 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 jaringan dan instance sekunder.
Ubah primer dengan beberapa cara—misalnya, menambahkan tabel atau menyisipkan beberapa data.
Lakukan proses failover seperti yang diuraikan sebelumnya sehingga sekunder menjadi primer baru.

Langkah-langkah untuk proses failover sama dengan skenario ideal, kecuali tabel yang ditambahkan ke {i>primary <i}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 sesuai 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 lebih awal (lihat Menambahkan instance sekunder ke cluster failover sebelumnya) dengan perbedaan berikut: node-3 sekarang menjadi yang utama, bukan node-1. Anda perlu mengganti {i>instance <i}apa pun node-3 dengan nama server yang Anda tambahkan ke grup ketersediaan. Jika menggunakan kembali VM yang sama (node-1 dan node-2), Anda tidak perlu menambahkan server ke Windows Server Failover Cluster; hanya menambahkan SQL Server kembali ke grup ketersediaan.

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

Failover otomatis

Secara otomatis gagal ke instance sekunder karena instance utama dapat membuat menyelesaikan semua jenis permasalahan. Setelah {i>primary <i}yang asli kembali tersedia, Situasi ini dapat terjadi jika beberapa klien mengakses sekunder sementara yang lain menulis ke primer yang dipulihkan. Dalam hal ini, primer dan sekunder mungkin diperbarui secara paralel, dan statusnya berbeda. Untuk menghindari situasi ini, memberikan petunjuk untuk failover manual saat Anda memutuskan apakah (atau kapan) untuk gagal.

Jika Anda menerapkan failover otomatis, Anda harus memastikan bahwa hanya salah satu yang dikonfigurasi adalah instance utama dan dapat diubah. Setiap mode standby atau instance sekunder tidak boleh menyediakan akses tulis ke klien mana pun (kecuali utama untuk replikasi status). Selain itu, Anda harus menghindari jangkau jaringan failover berikutnya dalam waktu singkat. Misalnya, failover setiap lima menit tidak akan menjadi strategi pemulihan bencana yang bisa 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 (disaster recovery) dengan model yang menjadi instance utama dalam failover, seperti ditunjukkan dalam diagram berikut.

Instance utama dan standby dalam mode sinkron berada di zona yang berbeda di satu region, dan instance sekunder dalam mode asinkron berada di region lain.

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

Artinya, jika terjadi failover, deployment yang dihasilkan memiliki satu 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 ini adalah replika dari instance utama. Jika terjadi failover, Anda dapat mengonfigurasi ulang salah satu instance sekunder sebagai standby. Diagram berikut menunjukkan sebelum dan sesudah failover.

Dua instance sekunder berada di zona terpisah di region R2.

Gambar 7. Arsitektur standar pemulihan dari bencana dengan dua jaringan sekunder instance Compute Engine.

Setelah failover, salah satu instance sekunder di region R2 akan menjadi instance standby.

Gambar 8. Arsitektur standar pemulihan dari bencana dengan dua jaringan sekunder yang sama 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 pengaturan yang serupa dengan arsitektur 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 terjadi kegagalan region utama.

Pembersihan

Agar tidak menimbulkan tagihan ke akun Google Cloud Anda untuk resource yang digunakan dalam tutorial ini:

Menghapus project

Di konsol Google Cloud, buka halaman Manage resource.
Buka Manage resource
Pada daftar project, pilih project yang ingin Anda hapus, lalu klik Delete.
Pada dialog, ketik project ID, lalu klik Shut down untuk menghapus project.

Langkah berikutnya

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