Memigrasikan Microsoft SQL Server dari AWS ke Google Cloud

Memahami migrasi database

Migrasi database memindahkan data dari database sumber ke database target. Secara umum, Anda dapat memigrasikan subset data atau memiliki skema berbeda dalam database sumber dan target. Namun, tutorial ini menangani migrasi database homogen yang memerlukan migrasi database lengkap tanpa perubahan—database target adalah salinan database sumber.

Migrasi database tanpa periode nonaktif

Istilah tanpa periode nonaktif mengacu pada fakta bahwa selama migrasi, klien yang mengakses database sumber akan tetap beroperasi sepenuhnya dan tidak terganggu. Satu-satunya periode nonaktif terjadi saat klien harus terhubung kembali ke database target setelah migrasi selesai. Meskipun metode ini bukan benar-benar tanpa periode nonaktif, istilah ini mengacu pada skenario periode nonaktif minimal.

Untuk pembahasan umum tentang migrasi database, lihat Migrasi Database - Konsep dan Prinsip (Bagian 1) dan Migrasi Database - Konsep dan Prinsip (Bagian 2). Artikel ini menyediakan ringkasan tentang kemungkinan kompleksitas migrasi database dalam berbagai skenario.

Migrasi database menggunakan teknologi Microsoft SQL Server

Beberapa teknologi migrasi database menyediakan komponen dan layanan terpisah. Jika migrasi database memerlukan salinan database sumber, Anda dapat menggunakan teknologi Microsoft SQL Server bawaan.

Tutorial ini menggunakan teknologi Grup Ketersediaan Always On Microsoft SQL Server untuk menghubungkan database sumber (utama) ke database target (sekunder). Teknologi ini menyediakan replikasi asinkron dari database utama ke sekunder. Karena database utama berada di Amazon EC2 dan database sekunder ada di Google Cloud pada Compute Engine, replikasi tersebut akan menyelesaikan migrasi database. Setelah semua data dimigrasikan melalui replikasi asinkron, database sekunder dipromosikan ke utama dan klien dapat terhubung kembali ke database utama baru untuk melanjutkan pemrosesan.

Pendekatan ini mendukung pengujian eksplisit dengan replikasi uji coba ke dalam database target pengujian: Anda dapat memulai replikasi, membiarkannya tetap berjalan untuk sementara waktu, kemudian menghentikan replikasi. Database target pengujian memiliki status yang konsisten, dan Anda dapat menggunakannya untuk menguji aplikasi. Setelah pengujian selesai, Anda dapat menghapus database target pengujian, dan memulai replikasi untuk database live.

Arsitektur migrasi database multi-cloud

Diagram berikut menunjukkan keseluruhan arsitektur deployment untuk migrasi database multi-cloud:

Diagram sebelumnya menunjukkan Database Server SQL sumber (utama) di AWS sebagai instance Amazon EC2. Diagram ini juga menunjukkan database target (sekunder) di Google Cloud. Database terhubung oleh Grup Ketersediaan Always On. Koneksi jaringan antara AWS dan Google Cloud dianggap sebagai koneksi VPN dengan ketersediaan tinggi (HA).

Menyiapkan grup ketersediaan Microsoft SQL Server multi-cloud

Di bagian berikut ini, Anda menyiapkan dua node Grup Ketersediaan Always On tempat node utama berada di AWS, dan node sekunder berada di Google Cloud. Konfigurasi ini telah dijelaskan sebelumnya dalam dokumen ini di Arsitektur migrasi database multi-cloud.

Tabel berikut menyediakan ringkasan node dan alamat IP yang Anda siapkan dalam tutorial ini. Untuk setiap VM database, Anda perlu mengalokasikan dua alamat IP selain alamat IP utama: satu alamat IP untuk Windows Server Failover Cluster (WSFC) dan satu alamat IP untuk Pemroses Grup Ketersediaan.

Petunjuknya menggunakan nama dan alamat IP ini sebagai contoh. Jika Anda ingin menggunakan nama dan alamat IP Anda sendiri, ganti contoh nilai dalam petunjuk.

Prasyarat untuk AWS

Pada AWS, Anda harus memiliki dua virtual machine: satu yang menjalankan pengontrol domain, dan satu lagi yang menjalankan SQL Server. Pengontrol domain yang digunakan sebagai contoh dalam tutorial ini memiliki konfigurasi berikut:

Domain                    : dbeng.com
Domain controller         : Name: dc-windows
                            Private IP: 192.168.1.100
VPC Subnet                : 192.168.1.0/24
SQL Server service account: dbeng\sql_service

VM SQL Server yang digunakan sebagai contoh dalam tutorial ini adalah bagian dari domain Windows Active Directory di Amazon EC2. Server memiliki dua alamat IP sekunder untuk digunakan oleh WSFC dan Pemroses Grup Ketersediaan. VM SQL Server memiliki konfigurasi berikut:

VM Instance : Name: cluster-sql1
              Private IP: 192.168.1.4
              Secondary Private IPs: 192.168.1.5, 192.168.1.6
VPC Subnet  : 192.168.1.0/24

Anda dapat menggunakan akun layanan NT SERVICE\MSSQLSERVER sebagai akun layanan SQL Server. Selama penyiapan Grup Ketersediaan Always On, Anda memberikan akses ke akun perangkat (dbeng\cluster-sql1$, dbeng\cluster-sql2$) bukan akun domain. Bagian berikut menyediakan perintah untuk mengonfigurasi grup ketersediaan.

Prasyarat untuk konektivitas antara AWS dan Google Cloud

Untuk menghubungkan project AWS Anda dengan project Google Cloud Anda, siapkan konektivitas jaringan berikut:

1. Siapkan Virtual Private Cloud Google dan VPC AWS di project Anda masing-masing, serta konfigurasikan VPN di antara VPC. Untuk mengetahui informasi tentang cara menyiapkan VPN antara Google Cloud dan AWS, lihat VPN multi-cloud dan subnetwork multi-zona — penyiapan jaringan untuk deployment database multi-cloud.

2. Di Cloud Shell, buat subnet di project Google Cloud tempat Anda membuat instance SQL Server. Jika Anda sudah memiliki subnet, Anda dapat menggunakannya. Namun, pastikan untuk menyiapkan aturan firewall pada langkah berikutnya.

   gcloud compute networks create demo-vpc --subnet-mode custom
   
   gcloud compute networks subnets create demo-subnet1 \
     --network demo-vpc --region us-east4 --range 10.1.1.0/24
   

   Tutorial ini menggunakan nilai-nilai berikut:

   • VPC: demo-vpc
   • Subnet: demo-subnet1; 10.1.1.0/24

   Subnet muncul pada halaman jaringan VPC Konsol Google Cloud.

3. Di project Google Cloud Anda, buat aturan firewall untuk membuka semua traffic antara subnet Google Cloud Anda dan subnet AWS Anda:

   gcloud compute firewall-rules create allow-vpn-ports \
     --network demo-vpc --allow tcp:1-65535,udp:1-65535,icmp \
     --source-ranges 10.1.1.0/24,192.168.1.0/24
   

   Aturan firewall muncul pada halaman Kebijakan firewall Konsol Google Cloud.

4. Pada project AWS Anda, buat aturan firewall di Grup Keamanan untuk membuka semua traffic antara subnet Google Cloud Anda dan subnet AWS Anda, seperti yang ditunjukkan pada screenshot berikut:

   

   Dalam lingkungan produksi, Anda dapat mempertimbangkan untuk hanya membuka port TCP/UDP yang diperlukan. Hanya membuka port yang diperlukan akan membatasi traffic yang berpotensi bahaya dan mengikuti prinsip yang paling tidak diperlukan.

Membuat instance di Google Cloud untuk Grup Ketersediaan Always On

Tutorial ini berfungsi dengan edisi dan fitur Microsoft SQL Server berikut:

• Edisi:
  • Microsoft SQL Server 2016 Edisi Perusahaan, atau
  • Microsoft SQL Server 2017 Edisi Perusahaan, atau
  • Microsoft SQL Server 2019 Edisi Perusahaan, atau
  • Microsoft SQL Server 2022 Edisi Perusahaan, atau
  • Microsoft SQL Server 2016 Edisi Standard, atau
  • Microsoft SQL Server 2017 Edisi Standard, atau
  • Microsoft SQL Server 2019 Edisi Standard, atau
  • Microsoft SQL Server 2022 Edisi Standard
• Fitur: Grup Ketersediaan Always On

Petunjuk berikut menggunakan image untuk Microsoft SQL Server 2019 Edisi Perusahaan: sql-ent-2019-win-2019. Jika Anda ingin menginstal Microsoft SQL Server 2017, 2016, atau 2022 Edisi Perusahaan, gunakan sql-ent-2017-win-2019, sql-ent-2016-win-2019, secara berurutan sql-ent-2022-win-2019, sebagai gantinya. Untuk mengetahui daftar semua image, lihat halaman Detail sistem operasi Compute Engine.

Pada langkah-langkah berikut, Anda membuat instance SQL Server di Google Cloud untuk grup ketersediaan. Instance ini menggunakan konfigurasi alamat IP berikut dengan alamat IP Alias:

VM Instance: Name: cluster-sql2
             Private IP: 10.1.1.4
             Secondary Private IPs: 10.1.1.5, 10.1.1.6

Anda membuat instance bernama cluster-sql2 dari image SQL Server publik, dengan ukuran boot disk sebesar 200 GB dan jenis mesin n1-highmem-4. Instance SQL Server biasanya memerlukan lebih banyak resource komputasi daripada instance pengontrol domain. Jika nantinya Anda memerlukan resource komputasi tambahan, Anda dapat mengubah jenis mesin untuk instance ini. Jika Anda memerlukan ruang penyimpanan tambahan, tambahkan disk atau ubah ukuran persistent boot disk. Dalam grup ketersediaan yang lebih besar, Anda dapat membuat beberapa instance.

Langkah-langkah berikut juga menyertakan flag --metadata sysprep-specialize-script-ps1 yang menjalankan perintah Microsoft PowerShell selama pembuatan instance untuk menginstal fitur Failover Clustering.

1. Di Cloud Shell, buat instance SQL Server di Google Cloud yang menggunakan versi sistem operasi yang sama seperti di AWS:

   gcloud compute instances create cluster-sql2 --machine-type n1-highmem-4 \
     --boot-disk-type pd-ssd --boot-disk-size 200GB \
     --image-project windows-sql-cloud --image-family sql-ent-2019-win-2019 \
     --zone us-east4-a \
     --network-interface "subnet=demo-subnet1,private-network-ip=10.1.1.4,aliases=10.1.1.5;10.1.1.6" \
     --can-ip-forward \
     --metadata sysprep-specialize-script-ps1="Install-WindowsFeature Failover-Clustering -IncludeManagementTools;"
   

2. Tetapkan nama pengguna dan sandi Windows sebelum Anda terhubung ke instance.

3. Saat Anda menggunakan Remote Desktop Protocol (RDP) dari laptop, Anda, buat aturan firewall yang mengizinkan akses ke instance tersebut.

4. Hubungkan ke instance Google Cloud menggunakan RDP dan buka PowerShell yang telah ditingkatkan (jalankan sebagai administrator).

5. Dalam tutorial ini, Anda mengonfigurasi DNS lokal untuk menggunakan pengontrol domain di AWS (192.168.1.100) agar tidak membuat VM lain di Google Cloud. Untuk workload produksi, sebaiknya Anda menggunakan pengontrol domain (utama atau sekunder) di Google Cloud untuk menghindari autentikasi melalui tunnel VPN.

   Di PowerShell yang telah ditingkatkan, Anda akan dapat melakukan ping pada pengontrol domain 192.168.1.100:

   ping 192.168.1.100
   

   Jika ping gagal, pastikan firewall dan tunnel VPN dikonfigurasi dengan benar antara AWS dan Google Cloud, seperti yang dijelaskan dalam Prasyarat untuk konektivitas di awal dokumen ini.

6. Karena server awalnya disiapkan dengan DHCP, ubah instance untuk menggunakan alamat IP statis:

   netsh interface ip set address name=Ethernet static 10.1.1.4 255.255.255.0 10.1.1.1 1
   

   Setelah Anda menjalankan perintah sebelumnya, koneksi Anda akan terputus. Hubungkan kembali di RDP.

7. Konfigurasikan DNS lokal untuk menggunakan pengontrol domain di AWS dan buka port firewall lokal untuk SQL Server. Membuka port firewall memungkinkan SQL Server terhubung ke SQL Server jarak jauh.

   netsh interface ip set dns Ethernet static 192.168.1.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 tersebut akan meminta kredensial administrator domain Anda. Setelah perintah selesai dijalankan, instance akan dimulai ulang.

   Jika perintah tidak dijalankan, pastikan Anda menjalankannya sebagai administrator.

9. Gunakan akun dbeng\Administrator untuk terhubung kembali ke instance Anda menggunakan RDP.

10. Setel akun layanan SQL Server:

    1. Buka SQL Server 2019 Configuration Manager.
    2. Pada tab Layanan SQL Server, klik kanan SQL Server (MSSQLSERVER), kemudian klik Properti.
    3. Tetapkan akun dan sandi untuk dbeng\sql_service.
    4. Mulai ulang SQL Server.

11. Ganti nama instance SQL Server agar sesuai dengan nama komputer, lalu mulai ulang SQL Server:

    Invoke-Sqlcmd -Query "EXEC sp_dropserver @@SERVERNAME, @droplogins='droplogins'"
    
    Invoke-Sqlcmd -Query "EXEC sp_addserver '$env:COMPUTERNAME', local"
    
    Stop-Service -Name "MSSQLServer" -Force
    
    Start-Service -Name "MSSQLServer"
    

Selanjutnya, Anda mengonfigurasi instance di AWS.

Mengonfigurasi instance di AWS

Tutorial ini mengasumsikan bahwa Anda telah mengonfigurasi hal berikut di AWS:

• Instance SQL Server adalah bagian dari domain Active Directory.
• DNS lokal berfungsi dengan benar dan nama server jarak jauh di Google Cloud (cluster-sql2.dbeng.com) dapat diterjemahkan menjadi alamat IP.
• Aturan firewall dibuka di antara subnet di AWS dan Google Cloud.

Untuk mengonfigurasi cluster-sql1 di AWS, lakukan hal berikut:

1. Hubungkan ke instance AWS menggunakan RDP (cluster-sql1).
2. Buka PowerShell yang telah ditingkatkan (jalankan sebagai administrator).

3. Instal Windows Failover Clustering jika belum diinstal.

   Install-WindowsFeature Failover-Clustering -IncludeManagementTools
   

   Perintah ini memerlukan mulai ulang jika fitur belum diinstal. Setelah mulai ulang, lanjutkan dengan langkah berikutnya.

4. Buka port firewall lokal untuk instance SQL Server di AWS:

   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
   
   netsh advfirewall firewall add rule name="ICMP Allow incoming V4 echo request" protocol="icmpv4:8,any" dir=in action=allow
   

5. Ganti nama instance SQL Server agar sesuai dengan nama komputer, lalu mulai ulang SQL Server:

   Invoke-Sqlcmd -Query "EXEC sp_dropserver @@SERVERNAME, @droplogins='droplogins'"
   
   Invoke-Sqlcmd -Query "EXEC sp_addserver '$env:COMPUTERNAME', local"
   
   Stop-Service -Name "MSSQLServer" -Force
   
   Start-Service -Name "MSSQLServer"
   

6. Validasi bahwa instance di AWS dapat terhubung ke instance di Google Cloud saat menggunakan nama instance jarak jauh. Untuk menguji koneksi, jalankan perintah berikut dari akun domain yang telah memberikan akses koneksi ke SQL Server.

   1. Uji koneksi jaringan:

      ping -4 cluster-sql2.dbeng.com
      

      Outputnya akan terlihat seperti berikut:

      RESULTS:
      Pinging cluster-sql2.dbeng.com [10.1.1.4] with 32 bytes of data:
      Reply from 10.1.1.4: bytes=32 time=3ms TTL=127
      Reply from 10.1.1.4: bytes=32 time=2ms TTL=127
      Reply from 10.1.1.4: bytes=32 time=2ms TTL=127
      Reply from 10.1.1.4: bytes=32 time=2ms TTL=127
      

   2. Uji Autentikasi Windows ke server jarak jauh:

      sqlcmd -E -S cluster-sql2.dbeng.com -Q "SELECT 'CONNECTED'"
      

      Outputnya akan terlihat seperti berikut:

      RESULTS:
      --------------------------------------------------------------------------
      CONNECTED
      
      (1 rows affected)
      

   Jika Anda tidak dapat terhubung, pastikan DNS berfungsi dengan benar dan aturan firewall terbuka di antara subnet AWS dan Google Cloud.

Memverifikasi instance Google Cloud yang siap bergabung ke grup ketersediaan

1. Gunakan akun dbeng\Administrator untuk terhubung ke instance Google Cloud menggunakan RDP (cluster-sql2).
2. Buka PowerShell yang telah ditingkatkan (jalankan sebagai administrator).

3. Validasikan bahwa instance di Google Cloud dapat terhubung ke instance di AWS saat menggunakan nama instance. Untuk menguji koneksi, jalankan perintah berikut dari akun domain yang telah memberikan akses koneksi ke SQL Server.

   1. Uji koneksi jaringan:

      ping -4 cluster-sql1.dbeng.com
      

      Outputnya akan terlihat seperti berikut:

      RESULTS:
      Pinging CLUSTER-SQL1.dbeng.com [192.168.1.4] with 32 bytes of data:
      Reply from 192.168.1.4: bytes=32 time=3ms TTL=127
      Reply from 192.168.1.4: bytes=32 time=2ms TTL=127
      Reply from 192.168.1.4: bytes=32 time=3ms TTL=127
      Reply from 192.168.1.4: bytes=32 time=2ms TTL=127
      

   2. Uji Autentikasi Windows ke server jarak jauh:

      sqlcmd -E -S cluster-sql1 -Q "SELECT 'CONNECTED'"
      

      Outputnya akan terlihat seperti berikut:

      RESULTS:
      ------------------------------------------------------------
      CONNECTED
      
      (1 rows affected)
      

      Jika Anda tidak dapat terhubung, pastikan DNS berfungsi dengan benar dan aturan firewall terbuka di antara subnet AWS dan Google Cloud.

4. Buat folder di C:\SQLData dan C:\SQLLog. Data database dan file log menggunakan folder ini.

   New-Item "C:\SQLData" –type directory
   New-Item "C:\SQLLog" –type directory
   

5. Buat folder di C:\SQLBackup dan file berbagi Windows di \\cluster-sql2\SQLBackup untuk mentransfer cadangan dari instance AWS. Anda dapat menggunakan jaringan bersama lainnya yang tersedia untuk kedua server.

   New-Item "C:\SQLBackup" –type directory
   New-SmbShare -Name "SQLBackup" -Path "C:\SQLBackup" -FullAccess
   "dbeng.com\cluster-sql1$","dbeng.com\cluster-sql2$","NT
   SERVICE\MSSQLSERVER","authenticated users","dbeng.com\sql_service"
   

Instance sekarang siap untuk grup ketersediaan. Karena Anda hanya memiliki dua instance, di bagian berikutnya, Anda mengonfigurasi saksi berbagi file untuk menyediakan suara penentu dan mencapai kuorum.

Membuat saksi berbagi file

Untuk menyediakan suara penentu dan mencapai quorum untuk skenario failover, buat fitur berbagi file yang bertindak sebagai saksi. Untuk tujuan tutorial ini, Anda membuat saksi berbagi file pada VM pengontrol domain. Dalam lingkungan produksi, Anda akan membuat saksi berbagi file pada server mana pun dalam domain Active Directory Anda.

1. Gunakan akun dbeng\Administrator untuk terhubung ke VM pengontrol domain, dc-windows, menggunakan RDP.
2. Buka PowerShell yang telah ditingkatkan (jalankan sebagai administrator).

3. Buat folder saksi:

   New-Item "C:\QWitness" –type directory
   

4. Bagikan folder:

   New-SmbShare -Name "QWitness" -Path "C:\QWitness" -Description "SQL File Share Witness" -FullAccess "dbeng.com\Administrator", "dbeng.com\cluster-sql1$", "dbeng.com\cluster-sql2$"
   

5. Gunakan dbeng.com\Administrator untuk terhubung ke cluster-sql1 dan cluster-sql2 menggunakan RDP.

6. Pastikan Anda dapat mengakses direktori bersama dari kedua server:

   dir \\dc-windows\QWitness
   

   Jika Anda tidak dapat mengakses direktori bersama, coba ubah koneksi jaringan pada node untuk menetapkan server WINS agar cocok dengan server domain. Perubahan koneksi jaringan mungkin memerlukan waktu beberapa detik. Screenshot berikut menunjukkan setelan WINS yang telah diperbarui:

   

Sekarang semuanya siap untuk grup ketersediaan. Selanjutnya, Anda mengonfigurasi Failover Clustering.

Mengonfigurasi Failover Clustering

Di bagian ini, Anda mengonfigurasi WSFC dan mengaktifkan Ketersediaan Tinggi Always On untuk kedua instance. Jalankan semua perintah konfigurasi berikut dari instance di AWS.

1. Hubungkan ke instance AWS (cluster-sql1) menggunakan RDP.
2. Buka PowerShell yang telah ditingkatkan (jalankan sebagai administrator).

3. Tetapkan variabel yang mencerminkan lingkungan cluster Anda. Untuk contoh ini, tetapkan variabel berikut:

   $node1 = "cluster-sql1.dbeng.com"
   $node2 = "cluster-sql2.dbeng.com"
   $nameWSFC = "cluster-dbclus" #Name of cluster
   $ipWSFC1 = "192.168.1.5" #IP address of cluster in subnet 1 (AWS)
   $ipWSFC2 = "10.1.1.5"    #IP address of cluster in subnet 2 (Google Cloud)
   

4. Buat cluster failover (perintah ini mungkin memerlukan waktu beberapa saat untuk dijalankan):

   New-Cluster -Name $nameWSFC -Node $node1, $node2 -NoStorage -StaticAddress $ipWSFC1, $ipWSFC2
   
   Set-ClusterQuorum -FileShareWitness \\dc-windows\QWitness
   

5. Aktifkan Ketersediaan Tinggi Always On di node 1. Jika sebelumnya Anda belum mengaktifkan Always On, perintah ini akan memaksa SQL Server untuk memulai ulang.

   Enable-SqlAlwaysOn -ServerInstance $node1 -Force
   

6. Aktifkan Ketersediaan Tinggi Always On di node 2. Perintah ini menghentikan layanan SQL Server sebelum mengaktifkan SQL Always On, sehingga Anda dapat mengabaikan error yang bertuliskan: Enable-SqlAlwaysOn : StopService failed for Service 'MSSQLSERVER'.

   Get-Service -ComputerName $node2 -Name "MSSQLServer" | Stop-Service -Force
   
   Enable-SqlAlwaysOn -ServerInstance $node2 -Force
   
   Get-Service -ComputerName $node2 -Name "MSSQLServer" | Start-Service
   

7. Buat folder di C:\SQLData dan C:\SQLLog. Gunakan folder ini untuk data database dan file log TestDB. Jika server Anda sudah memiliki database dengan struktur folder ini, Anda dapat melewati langkah ini. Jika Anda tidak yakin, jalankan perintah dan abaikan pesan error apa pun tentang folder yang sudah ada.

   New-Item "C:\SQLData" –type directory
   New-Item "C:\SQLLog" –type directory
   

Pengelola Cluster Failover sudah siap. Selanjutnya, Anda membuat grup ketersediaan.

Membuat grup ketersediaan

Di bagian ini, Anda membuat database pengujian di AWS (cluster-sql1) dan mengonfigurasinya agar berfungsi dengan grup ketersediaan baru. Atau, Anda dapat menentukan database yang ada untuk grup ketersediaan.

1. Hubungkan ke instance AWS (cluster-sql1) menggunakan RDP.
2. Buka PowerShell yang telah ditingkatkan (jalankan sebagai administrator).

3. Buat folder di C:\SQLBackup untuk menyimpan cadangan database. Cadangan diperlukan sebelum Anda dapat menyiapkan grup ketersediaan di database baru.

   New-Item "C:\SQLBackup" –type directory
   

4. Jika Anda belum mengonfigurasi database, jalankan SQL Server Management Studio dan buat database pengujian di instance AWS (cluster-sql1):

   CREATE DATABASE TestDB
   ON PRIMARY (NAME = 'TestDB_Data', FILENAME='C:\SQLData\TestDB_Data.mdf', SIZE = 256MB, MAXSIZE = UNLIMITED, FILEGROWTH = 256MB )
   LOG ON (NAME = 'TestDB_Log', FILENAME='C:\SQLLog\TestDB_Log.ldf', SIZE = 256MB, MAXSIZE = UNLIMITED, FILEGROWTH = 256MB )
   GO
   
   USE [TestDB]
   Exec dbo.sp_changedbowner @loginame = 'sa', @map = false;
   ALTER DATABASE [TestDB] SET RECOVERY FULL;
   GO
   
   BACKUP DATABASE TestDB to disk = 'C:\SQLBackup\TestDB-backup.bak' WITH INIT
   GO
   

5. Di Microsoft SQL Server Management Studio, pilih Kueri > Mode SQLCMD.

   SQL Server Management Studio menyediakan wizard untuk membuat grup ketersediaan. Dalam tutorial ini, Anda akan menggunakan perintah SQL sehingga lebih mudah men-debug masalah yang mungkin Anda alami saat terhubung dengan berbagai penyedia cloud. Jika ingin, Anda dapat menjalankan wizard grup ketersediaan dan melanjutkan ke langkah berikutnya untuk verifikasi bahwa grup ketersediaan sedang disinkronkan.

6. Jalankan kueri berikut dalam Mode SQLCMD. Jika Anda menggunakan database yang sudah ada, ganti TestDB dengan nama database Anda.

   1. Buat endpoint di node pertama dan berikan izin ke endpoint:

      :Connect CLUSTER-SQL1
      IF NOT EXISTS (SELECT state FROM sys.endpoints WHERE name = N'Hadr_endpoint')
      BEGIN
        CREATE ENDPOINT [Hadr_endpoint]
        AS TCP (LISTENER_PORT = 5022)
        FOR DATA_MIRRORING (ROLE = WITNESS, ENCRYPTION = REQUIRED ALGORITHM AES)
      END
      GO
      
      IF (SELECT state FROM sys.endpoints WHERE name = N'Hadr_endpoint') <> 0
      BEGIN
        ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED
      END
      GO
      
      use [master]
      GO
      
      IF SUSER_ID('DBENG\sql_service') IS NULL
        CREATE LOGIN [DBENG\sql_service] FROM WINDOWS
      GO
      
      GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [DBENG\sql_service]
      GO
      

   2. Aktifkan sesi peristiwa AlwaysOn_health yang diperpanjang di node pertama. Grup Ketersediaan memerlukan sesi peristiwa yang diperpanjang.

      :Connect CLUSTER-SQL1
      IF EXISTS(SELECT * FROM sys.server_event_sessions WHERE name='AlwaysOn_health')
      BEGIN
        ALTER EVENT SESSION [AlwaysOn_health] ON SERVER WITH (STARTUP_STATE=ON);
      END
      IF NOT EXISTS(SELECT * FROM sys.dm_xe_sessions WHERE name='AlwaysOn_health')
      BEGIN
        ALTER EVENT SESSION [AlwaysOn_health] ON SERVER STATE=START;
      END
      GO
      

   3. Buat endpoint di node kedua dan berikan izin ke endpoint:

      :Connect CLUSTER-SQL2
      IF NOT EXISTS (SELECT state FROM sys.endpoints WHERE name = N'Hadr_endpoint')
      BEGIN
        CREATE ENDPOINT [Hadr_endpoint]
          AS TCP (LISTENER_PORT = 5022)
          FOR DATA_MIRRORING (ROLE = WITNESS, ENCRYPTION = REQUIRED ALGORITHM AES)
      END
      GO
      
      IF (SELECT state FROM sys.endpoints WHERE name = N'Hadr_endpoint') <> 0
      BEGIN
        ALTER ENDPOINT [Hadr_endpoint] STATE = STARTED
      END
      GO
      
      use [master]
      GO
      
      IF SUSER_ID('DBENG\sql_service') IS NULL
        CREATE LOGIN [DBENG\sql_service] FROM WINDOWS
      GO
      
      GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [DBENG\sql_service]
      GO
      

   4. Aktifkan sesi peristiwa AlwaysOn_health yang diperpanjang di node kedua. Grup Ketersediaan memerlukan sesi peristiwa yang diperpanjang.

      :Connect CLUSTER-SQL2
      IF EXISTS(SELECT * FROM sys.server_event_sessions WHERE name='AlwaysOn_health')
      BEGIN
        ALTER EVENT SESSION [AlwaysOn_health] ON SERVER WITH (STARTUP_STATE=ON);
      END
      IF NOT EXISTS(SELECT * FROM sys.dm_xe_sessions WHERE name='AlwaysOn_health')
      BEGIN
        ALTER EVENT SESSION [AlwaysOn_health] ON SERVER STATE=START;
      END
      GO
      

   5. Buat Grup Ketersediaan di node pertama:

      :Connect CLUSTER-SQL1
      USE [master]
      GO
      
      --DROP AVAILABILITY GROUP [cluster-ag];
      GO
      
      CREATE AVAILABILITY GROUP [cluster-ag]
      WITH (AUTOMATED_BACKUP_PREFERENCE = SECONDARY,
      DB_FAILOVER = OFF,
      DTC_SUPPORT = NONE)
      FOR DATABASE [TestDB]
      REPLICA ON N'CLUSTER-SQL1' WITH (ENDPOINT_URL = N'TCP://CLUSTER-SQL1.dbeng.com:5022', FAILOVER_MODE = MANUAL, AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, BACKUP_PRIORITY = 50, SEEDING_MODE = MANUAL),
        N'CLUSTER-SQL2' WITH (ENDPOINT_URL = N'TCP://cluster-sql2.dbeng.com:5022', FAILOVER_MODE = MANUAL, AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT, BACKUP_PRIORITY = 50, SEEDING_MODE = MANUAL);
      GO
      

   6. Gabungkan node kedua ke Grup Ketersediaan yang baru dibuat:

      :Connect CLUSTER-SQL2
      ALTER AVAILABILITY GROUP [cluster-ag] JOIN;
      GO
      

   7. Buat cadangan database di node pertama:

      :Connect CLUSTER-SQL1
      BACKUP DATABASE [TestDB] TO DISK = N'\\CLUSTER-SQL2\SQLBackup\TestDB.bak' WITH COPY_ONLY, FORMAT, INIT, SKIP, REWIND, NOUNLOAD, COMPRESSION, STATS = 5
      GO
      

   8. Pulihkan cadangan database pada node kedua:

      :Connect CLUSTER-SQL2
      RESTORE DATABASE [TestDB] FROM DISK = N'\\CLUSTER-SQL2\SQLBackup\TestDB.bak' WITH NORECOVERY, NOUNLOAD, STATS = 5
      GO
      

   9. Buat cadangan log transaksi di node pertama:

      :Connect CLUSTER-SQL1
      BACKUP LOG [TestDB] TO DISK = N'\\CLUSTER-SQL2\SQLBackup\TestDB.trn' WITH NOFORMAT, INIT, NOSKIP, REWIND, NOUNLOAD, COMPRESSION, STATS = 5
      GO
      

   10. Pulihkan cadangan log transaksi di node kedua:

       :Connect CLUSTER-SQL2
       RESTORE LOG [TestDB] FROM  DISK = N'\\CLUSTER-SQL2\SQLBackup\TestDB.trn' WITH NORECOVERY, NOUNLOAD, STATS = 5
       GO
       

7. Untuk memastikan tidak ada error dalam sinkronisasi, jalankan kueri berikut dan pastikan kolom connected_state_desc memiliki nilai CONNECTED:

   :Connect CLUSTER-SQL2
   select r.replica_server_name, r.endpoint_url,
          rs.connected_state_desc, rs.last_connect_error_description,
          rs.last_connect_error_number, rs.last_connect_error_timestamp
    from sys.dm_hadr_availability_replica_states rs
     join sys.availability_replicas r
      on rs.replica_id=r.replica_id
    where rs.is_local=1
   

   • Jika kolom connected_state_desc memiliki pesan error An error occurred while receiving data: '24(The program issued a command but the command length is incorrect)', jalankan perintah berikut untuk mencoba menghapus error:

     :Connect CLUSTER-SQL1
     IF SUSER_ID('DBENG\CLUSTER-SQL2$') IS NULL
        CREATE LOGIN [DBENG\CLUSTER-SQL2$] FROM WINDOWS
     GO
     
     GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [DBENG\CLUSTER-SQL2$]
     GO
     
     :Connect CLUSTER-SQL2
     IF SUSER_ID('DBENG\CLUSTER-SQL1$') IS NULL
       CREATE LOGIN [DBENG\CLUSTER-SQL1$] FROM WINDOWS
     GO
     
     GRANT CONNECT ON ENDPOINT::[Hadr_endpoint] TO [DBENG\CLUSTER-SQL1$]
     GO
     

     Jalankan kembali kueri sebelumnya untuk memastikan error sinkronisasi tidak terjadi lagi. Anda mungkin perlu menunggu beberapa menit sampai error teratasi. Jika error tetap berlanjut, lihat Memecahkan Masalah Konfigurasi Grup Ketersediaan Always On (SQL Server).

8. Selesaikan penyiapan grup ketersediaan:

   :Connect CLUSTER-SQL2
   ALTER DATABASE [TestDB] SET HADR AVAILABILITY GROUP = [cluster-ag]
   GO
   
   ALTER DATABASE [TestDB] SET HADR RESUME;
   GO
   

9. Verifikasi bahwa grup ketersediaan sedang disinkronkan:

   1. Di SQL Server Management Studio, di bagian Ketersediaan Tinggi Always On > Grup Ketersediaan, klik kanan grup ketersediaan, kemudian pilih Tampilkan Dasbor.

   2. Pastikan Status Sinkronisasi utama adalah Tersinkronkan, dan Status Sinkronisasi sekunder Menyinkronkan, seperti ditunjukkan pada screenshot berikut:

      

10. Untuk menambahkan pemroses, di bagian Ketersediaan Tinggi Always On > Grup Ketersediaan > cluster-ag (Primary) > Pemroses Grup Ketersediaan, klik kanan nama grup ketersediaan, kemudian pilih Tambahkan Pemroses.

11. Pada dialog Pemroses Grup Ketersediaan Baru tetapkan parameter berikut untuk pemroses:

    • Nama DNS Pemroses: ag-listener
    • Port: 1433
    • Mode Jaringan: Static IP

12. Tambahkan dua kolom subnet dan alamat IP. Untuk contoh ini, gunakan pasangan subnet dan alamat IP berikut. Pasangan ini adalah alamat IP yang Anda buat selain alamat IP utama pada VM instance Layanan SQL:

    1. Untuk pasangan pertama, masukkan nilai berikut:
       • Subnet: 192.168.1.0/24
       • Alamat IPv4: 192.168.1.6
    2. Untuk pasangan kedua, masukkan nilai berikut:
       • Subnet: 10.1.1.0/24
       • Alamat IPv4: 10.1.1.6

13. Setelah Anda selesai menambahkan pasangan subnet dan alamat IP, klik OK.

14. Hubungkan ke SQL Server menggunakan ag-listener.dbeng.com sebagai nama database SQL Server, bukan nama instance. Koneksi ini mengarah ke instance yang sedang aktif.

    1. Di Object Explorer, klik Hubungkan, kemudian pilih Mesin Database.
    2. Pada dialog Hubungkan ke Server, di kolom nama Server, masukkan nama pemroses ag-listener.dbeng.com.

    3. Setelah menambahkan nama server, klik Hubungkan. Object Explorer menampilkan koneksi baru, seperti yang ditunjukkan di screenshot berikut:

       

    Jika Anda terhubung ke cluster-sql2 menggunakan RDP, Anda dapat secara opsional mengulangi langkah ini untuk membuat koneksi.

Menambahkan data pengujian

Di bagian ini, Anda menambahkan tabel pengujian dan beberapa data pengujian ke database TestDB di cluster-sql1, kemudian memverifikasi replikasi data.

1. Buat tabel bernama Persons di cluster-sql1:

   :Connect CLUSTER-SQL1
   USE TestDB;
   CREATE TABLE Persons (
       PersonID int,
       LastName varchar(255),
       FirstName varchar(255),
       PRIMARY KEY (PersonID)
   );
   

2. Sisipkan beberapa baris:

   :Connect CLUSTER-SQL1
   USE TestDB;
   INSERT INTO Persons (PersonId, LastName, FirstName)
     VALUES (1, 'Velasquez', 'Ava');
   INSERT INTO Persons (PersonId, LastName, FirstName)
     VALUES (2, 'Delaxcrux', 'Paige');
   

3. Jika Anda menggunakan edisi Perusahaan, aktifkan akses baca replika baca (cluster-sql2) sehingga Anda dapat memverifikasi bahwa replikasi tersebut terjadi. Edisi Standard tidak mendukung akses hanya baca ke replika baca. Jika Anda menggunakan edisi Standard, lanjutkan ke bagian berikutnya untuk menjalankan migrasi sistem ke Google Cloud.

   :Connect CLUSTER-SQL1
   ALTER AVAILABILITY GROUP [cluster-ag]
   MODIFY REPLICA ON N'CLUSTER-SQL2' WITH (SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL))
   GO
   

4. Pada edisi Perusahaan, buat kueri tabel di cluster-sql2 untuk memverifikasi bahwa konten tabel telah direplikasi:

   :Connect CLUSTER-SQL2
   SELECT * FROM TestDB.dbo.Persons;
   

Setelah data direplikasi dari cluster-sql1 ke cluster-sql2, Anda akan menjalankan migrasi sistem. Jika Anda hanya ingin melakukan replikasi, Anda dapat melewati bagian berikut dan tidak menjalankan migrasi sistem atau penggantian. Jika Anda tidak ingin menyimpan resource yang Anda gunakan untuk melakukan replikasi, Anda dapat menghindari tagihan dengan mengikuti langkah-langkah pembersihan di akhir tutorial ini.

Menjalankan migrasi sistem ke Google Cloud

Untuk memastikan set data yang konsisten, setiap klien yang menulis ke cluster-sql1 harus dihentikan agar semua data dapat direplikasi ke cluster-sql2 sebelum Anda menjalankan migrasi sistem.

Untuk memastikan konsistensi, semua data harus direplikasi sepenuhnya. Di bagian ini, Anda menyelesaikan replikasi data lengkap dengan mengubah mode ketersediaan menjadi SYNCHRONOUS_COMMIT. Perubahan ini memastikan replikasi lengkap dari cluster-sql1 menjadi cluster-sql2.

1. Untuk mengubah mode ketersediaan kedua node menjadi commit sinkron, jalankan perintah SQL berikut di cluster-sql1. Menetapkan kedua node ke commit sinkron adalah satu-satunya cara untuk memastikan tidak ada data yang hilang.

   :Connect CLUSTER-SQL1
   ALTER AVAILABILITY GROUP [cluster-ag]
   MODIFY REPLICA ON N'CLUSTER-SQL1' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
   GO
   
   ALTER AVAILABILITY GROUP [cluster-ag]
   MODIFY REPLICA ON N'CLUSTER-SQL2' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT)
   GO
   

2. Cluster-sql2 sekarang siap menjadi node utama. Hubungkan ke cluster-sql2 dan jadikan sebagai node utama:

   :Connect CLUSTER-SQL2
   ALTER AVAILABILITY GROUP [cluster-ag] FAILOVER;
   GO
   

3. Ubah mode ketersediaan menjadi commit asinkron di kedua node. Karena cluster-sql2 adalah node utama, jalankan perintah SQL berikut di cluster-sql2:

   :Connect CLUSTER-SQL2
   ALTER AVAILABILITY GROUP [cluster-ag]
   MODIFY REPLICA ON N'CLUSTER-SQL1' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
   GO
   
   ALTER AVAILABILITY GROUP [cluster-ag]
   MODIFY REPLICA ON N'CLUSTER-SQL2' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT)
   GO
   

   Sekarang Anda siap menggunakan cluster-sql2 sebagai node utama untuk aplikasi. cluster-sql1 adalah node sekunder yang direplikasi secara asinkron.

4. Setelah cluster-sql2 menjadi node utama, buat kueri tabel di cluster-sql2 untuk memverifikasi bahwa konten tabel telah direplikasi:

   :Connect CLUSTER-SQL2
   SELECT * FROM TestDB.dbo.Persons;
   

   Output-nya cocok dengan data pengujian yang Anda sisipkan ke dalam tabel sebelumnya dalam tutorial ini.

Untuk melakukan verifikasi replikasi lebih lanjut, Anda dapat membuat tabel baru dan menyisipkan satu baris pada node utama baru. Ketika tabel dan barisnya muncul di node sekunder, Anda tahu bahwa replikasi berfungsi.

Pengganti

Terkadang, Anda mungkin perlu beralih dari node utama baru ke node utama yang asli. Setelah Anda menyelesaikan migrasi sistem ke Google Cloud sebelumnya dalam tutorial ini, Anda membuat node utama sebelumnya (cluster-sql1) node sekunder dari node utama baru (cluster-sql2).

Untuk menyelesaikan penggantian, ikuti proses untuk menjalankan migrasi sistem ke Google Cloud, dan ganti nilai berikut:

• Ganti node utama yang asli (cluster-sql1) dengan node utama baru (cluster-sql2).
• Ganti node sekunder yang asli (cluster-sql2) dengan node sekunder baru (cluster-sql1).