Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Keterbatasan, catatan, dan Multi-AZ rekomendasi penerapan Microsoft SQL Server
Berikut ini adalah beberapa batasan saat bekerja dengan Multi-AZ penerapan pada RDS untuk instance SQL Server DB:
-
Cross-Region Multi-AZ tidak didukung.
Menghentikan instans DB RDS for SQL Server dalam deployment Multi-AZ tidak didukung.
-
Anda tidak dapat mengonfigurasi instans DB sekunder untuk menerima aktivitas baca basis data.
-
Multi-AZ dengan Always On Availability Groups (AG) mendukung optimasi dalam memori.
-
Multi-AZ dengan Always On Availability Groups (AG) tidak mendukung otentikasi Kerberos untuk pendengar grup ketersediaan. Hal ini karena pendengar tidak memiliki Nama Prinsipal Layanan (SPN).
-
Multi-AZ dengan replikasi tingkat blok saat ini hanya didukung untuk instance SQL Server Web Edition.
-
Anda tidak dapat mengganti nama database pada instance SQL Server DB yang ada dalam penerapan SQL Server. Multi-AZ Jika Anda perlu mengganti nama database pada instance seperti itu, matikan dulu Multi-AZ untuk instance DB, lalu ganti nama database. Akhirnya, nyalakan Multi-AZ kembali untuk instance DB.
-
Anda hanya dapat memulihkan instans Multi-AZ DB yang dicadangkan menggunakan model pemulihan penuh.
-
Multi-AZ penerapan memiliki batas 10.000 pekerjaan SQL Server Agent.
Jika Anda membutuhkan batas yang lebih tinggi, minta kenaikan dengan menghubungi Dukungan. Buka halaman Pusat AWS Dukungan
, masuk jika perlu, dan pilih Buat kasus. Pilih Peningkatan batas layanan. Lengkapi dan kirimkan formulir ini. -
Anda tidak dapat memiliki database offline pada instance SQL Server DB yang ada dalam penyebaran SQL Server Multi-AZ .
-
Metrik volume tidak tersedia untuk host sekunder instance menggunakan replikasi tingkat blok.
Berikut ini adalah beberapa catatan tentang bekerja dengan Multi-AZ penerapan pada RDS untuk instance SQL Server DB:
-
Amazon RDS mengekspos titik akhir pendengar grup ketersediaan
AG Selalu Aktif. Titik akhir terlihat di konsol, dan ditampilkan oleh operasi API DescribeDBInstancessebagai entri di bidang titik akhir. -
Amazon RDS mendukung failover multisubnet grup ketersediaan
. -
Untuk menggunakan SQL Server Multi-AZ dengan instans SQL Server DB di virtual private cloud (VPC), pertama buat grup subnet DB yang memiliki subnet di setidaknya dua Availability Zone yang berbeda. Kemudian, tetapkan grup subnet DB menjadi replika primer instans DB SQL Server.
-
Ketika instance DB dimodifikasi menjadi Multi-AZ penerapan, selama modifikasi itu memiliki status modifikasi. Amazon RDS membuat replika siaga dan membuat cadangan instans DB primer. Setelah proses tersebut selesai, status instans DB primer menjadi tersedia.
-
Multi-AZ deployments memelihara semua database pada node yang sama. Jika terjadi failover pada basis data di host primer, semua basis data SQL Server Anda akan melakukan failover sebagai satu unit atomis ke host siaga. Amazon RDS menyediakan host baru yang berkondisi baik dan mengganti host yang tidak berkondisi baik.
-
Multi-AZ dengan DBM, AG, atau replikasi tingkat blok mendukung replika siaga tunggal.
-
Dalam Multi-AZ penerapan, RDS untuk SQL Server membuat login SQL Server untuk memungkinkan Always On AG atau Database Mirroring. RDS membuat login dengan pola berikut,,
db_<dbiResourceId>_node1_logindb_<dbiResourceId>_node2_login, dan.db_<dbiResourceId>_witness_login -
RDS untuk SQL Server membuat login SQL Server untuk memungkinkan akses membaca replika. RDS membuat login dengan pola berikut,
db_<readreplica_dbiResourceId>_node_login. -
Anda mungkin menemukan adanya peningkatan latensi dibandingkan dengan deployment instans DB standar (dalam satu Zona Ketersediaan) karena replikasi data yang sinkron.
-
Waktu failover dipengaruhi oleh waktu yang diperlukan untuk menyelesaikan proses pemulihan. Transaksi besar akan meningkatkan waktu failover.
-
Dalam Multi-AZ penerapan SQL Server, reboot dengan failover reboot hanya instance DB utama. Setelah failover, instans DB primer akan menjadi instans DB sekunder baru. Parameter mungkin tidak diperbarui untuk Multi-AZ instance. Untuk mem-boot ulang tanpa failover, instans DB primer dan sekunder, serta parameter diperbarui setelah boot ulang. Jika instans DB tidak responsif, kami sarankan boot ulang tanpa failover.
Tabel berikut membandingkan bagaimana objek tingkat server direplikasi dalam RDS untuk Multi-AZ penerapan SQL Server menggunakan Database Mirroring (DBM) atau Always On Availability Groups (AG) versus replikasi tingkat blok.
| Objek | Pencerminan Database/Selalu Di AG | Block-level replikasi |
|---|---|---|
| Kredensial Masuk | Ya - direplikasi oleh Amazon RDS. DEFAULT_DATABASEProperti tidak direplikasi. Jangan gunakan DEFAULT_DATABASE saat membuat atau mengubah login pada instans DBM atau Always On AG. |
Ya — termasuk DEFAULT_DATABASE (tidak ada batasan). |
| Pengguna basis data dan izin | Ya - direplikasi melalui replikasi asli SQL Server (disimpan dalam database pengguna). | Ya. |
| User-defined peran server | Always On AG: Ya — direplikasi. DBM: Tidak — tidak direplikasi. | Ya. |
| Server tertaut | Tidak - disimpan dalam master database, yang berada di luar AG atau cermin. Buat server tertaut sebelum mengaktifkan Multi-AZ, atau buat ulang secara manual setelah failover. |
Ya — seluruh volume, termasuk database sistem, direplikasi. |
| SQL Server Audit | Sebagian — Spesifikasi Audit Database (dalam database pengguna) direplikasi. Audit Server dan Spesifikasi Audit Server tidak direplikasi. Anda harus membuat ini secara manual pada sekunder menggunakan AUDIT_GUID parameter untuk mencocokkan primer. |
Ya — semua objek audit direplikasi pada tingkat volume. |
tempdbkonfigurasi |
Opsional - aktifkan sinkronisasi dengan prosedur tersimpan berikut. Objek dan data sementara tidak pernah direplikasi. |
Ya - konfigurasi direplikasi pada tingkat volume. |
| Lowongan kerja SQL Server Agent | Opsional - aktifkan sinkronisasi dengan prosedur tersimpan berikut. Hanya langkah T-SQL pekerjaan dalam kategori yang didukung yang direplikasi. Jenis langkah SSIS, SSRS, ReplikasiPowerShell, dan Database Mail tidak direplikasi. |
Ya — semua pekerjaan direplikasi pada tingkat volume. |
| CDC (Ubah Pengambilan Data) | Sebagian — Metadata CDC dan tabel perubahan (dalam database pengguna) direplikasi. Pekerjaan pengambilan dan pembersihan (inmsdb) tidak direplikasi secara langsung. Amazon RDS menjatuhkan dan membuatnya kembali pada primer baru setelah failover menggunakan parameter yang direkam sebelumnya. Gunakan rds_set_configuration untuk mengatur parameter CDC di sekunder. |
Ya — semua objek CDC direplikasi pada tingkat volume. |
| Resource Governor | Ya - direplikasi oleh Amazon RDS. Untuk memverifikasi sinkronisasi, jalankan kueri berikut.
|
Ya. |
| Pemilik basis data | Tidak - pada contoh sekunder, pemilik database diatur keNT AUTHORITY\SYSTEM. Setelah failover, gunakan msdb.dbo.rds_changedbowner_to_rdsa untuk mengatur ulang kepemilikan. |
Ya — pemilik dilestarikan. |
Izin msdb |
Tidak - RDS untuk SQL Server tidak mereplikasi izin msdb database ke instance sekunder. Anda harus membuatnya kembali secara manual. |
Ya - direplikasi pada tingkat volume. |
Berikut ini adalah beberapa rekomendasi untuk bekerja dengan Multi-AZ penerapan pada RDS untuk instans Microsoft SQL Server DB:
-
Untuk basis data yang digunakan dalam produksi atau praproduksi, kami merekomendasikan opsi berikut:
Multi-AZ penerapan untuk ketersediaan tinggi
"IOPS yang Tersedia" untuk performa yang cepat dan konsisten
"Memori dioptimalkan" alih-alih "Tujuan umum"
-
Anda tidak dapat memilih Zona Ketersediaan (AZ) untuk instans sekunder, jadi ketika Anda melakukan deployment host aplikasi, pertimbangkan hal ini. Basis data Anda mungkin akan melakukan failover ke AZ lain, dan host aplikasi mungkin tidak berada di AZ yang sama dengan basis data. Untuk alasan ini, kami menyarankan Anda menyeimbangkan host aplikasi Anda di semua AZ di AWS Wilayah tertentu.
-
Untuk performa terbaik, jangan aktifkan Pencerminan Database, Always On AG, atau replikasi tingkat blok selama operasi pemuatan data yang besar. Jika Anda ingin pemuatan data secepat mungkin, selesaikan pemuatan data sebelum Anda mengonversi instans DB Anda menjadi Multi-AZ penerapan.
-
Aplikasi yang mengakses basis data SQL Server harus memiliki penanganan pengecualian yang mengambil kesalahan koneksi. Contoh kode berikut menunjukkan try/catch blok yang menangkap kesalahan komunikasi. Dalam contoh ini, pernyataan
breakkeluar dari loopwhilejika koneksi berhasil, tetapi mencoba ulang hingga 10 kali jika pengecualian ditampilkan.int RetryMaxAttempts = 10; int RetryIntervalPeriodInSeconds = 1; int iRetryCount = 0; while (iRetryCount < RetryMaxAttempts) { using (SqlConnection connection = new SqlConnection(DatabaseConnString)) { using (SqlCommand command = connection.CreateCommand()) { command.CommandText = "INSERT INTO SOME_TABLE VALUES ('SomeValue');"; try { connection.Open(); command.ExecuteNonQuery(); break; } catch (Exception ex) { Logger(ex.Message); iRetryCount++; } finally { connection.Close(); } } } Thread.Sleep(RetryIntervalPeriodInSeconds * 1000); } -
Jangan gunakan
Set Partner Offperintah saat bekerja dengan Multi-AZ instance menggunakan DBM atau AG. Perintah ini tidak didukung pada instance menggunakan replikasi tingkat blok. Misalnya, jangan melakukan hal berikut.--Don't do this ALTER DATABASE db1 SET PARTNER off -
Jangan tetapkan mode pemulihan ke
simple. Misalnya, jangan melakukan hal berikut.--Don't do this ALTER DATABASE db1 SET RECOVERY simple -
Jangan gunakan
DEFAULT_DATABASEparameter saat membuat login baru pada instans Multi-AZ DB kecuali menggunakan replikasi tingkat blok untuk ketersediaan tinggi, karena pengaturan ini tidak dapat diterapkan ke cermin siaga. Misalnya, jangan melakukan hal berikut.--Don't do this CREATE LOGIN [test_dba] WITH PASSWORD=foo, DEFAULT_DATABASE=[db2]Selain itu, jangan melakukan hal berikut.
--Don't do this ALTER LOGIN [test_dba] WITH DEFAULT_DATABASE=[db3]