SQL Server Sentiasa Aktif: Panduan Lengkap untuk DBA [2026]

SQL Server Always On ialah penyelesaian ketersediaan tinggi dan pemulihan bencana Microsoft yang komprehensif yang diperkenalkan dengan SQL Server 2012. Ia mewakili kemajuan yang ketara berbanding teknologi sebelumnya seperti pencerminan pangkalan data dan penghantaran log, memastikan akses berterusan kepada data sambil meminimumkan masa henti dan kehilangan data.

1.2 Mengapa Perniagaan Perlukan Penyelesaian yang Sentiasa Terpakai

Dalam ekonomi digital hari ini, masa henti pangkalan data secara langsung diterjemahkan kepada kehilangan hasil, reputasi yang rosak dan isu pematuhan peraturan. Organisasi memerlukan penyelesaian ketersediaan tinggi yang dapat menjamin masa operasi yang hampir berterusan sambil melindungi daripada pelbagai senario kegagalan.

Prosedur sandaran dan pemulihan tradisional tidak mencukupi untuk keperluan perniagaan moden. Apabila pangkalan data kritikal gagal, perniagaan tidak mampu membayar masa yang diperlukan untuk memulihkan daripada sandaran. Penyelesaian Always On menyediakan failover automatik yang boleh memulihkan perkhidmatan dalam beberapa saat atau minit dan bukannya berjam-jam, sekali gus mengurangkan kesan kegagalan sistem secara mendadak.

Selain ketersediaan asas, perniagaan perlu mengalihkan beban kerja intensif baca daripada pangkalan data pengeluaran, melaksanakan penyelenggaraan tanpa masa henti dan melindungi daripada bencana peringkat tapak. SQL Server Always On menangani semua keperluan ini melalui seni bina terpadu yang berskala daripada penggunaan kecil kepada sistem yang diedarkan secara global.

1.3 Konsep Utama: RTO, RPO, HA dan DR

Objektif Masa Pemulihan (RTO) mentakrifkan tempoh maksimum masa henti yang boleh diterima selepas kegagalan — berapa cepat pangkalan data mesti kembali dalam talian.

Objektif Titik Pemulihan (RPO) mentakrifkan kehilangan data maksimum yang boleh diterima yang diukur dari segi masa — berapa banyak data yang baru-baru ini didebitkan yang mampu hilang oleh perniagaan.

Ketersediaan Tinggi (HA) memberi tumpuan kepada meminimumkan masa henti yang disebabkan oleh kegagalan rutin seperti kerosakan perkakasan atau ranap perisian dalam pusat data yang sama.

Pemulihan Bencana (DR) menangani peristiwa bencana yang menjejaskan seluruh tapak, mengekalkan salinan data di lokasi yang berasingan secara geografi. Walaupun HA memberi tumpuan kepada meminimumkan masa henti, DR memberi tumpuan kepada memastikan perlindungan data dan kesinambungan perniagaan semasa insiden besar.

SQL Server Sentiasa Aktif menyokong kedua-dua HA dan DR dalam satu seni bina bersatu. Mod komit segerak memberikan RPO = 0 dengan failover automatik untuk RTO hampir sifar; mod komit tak segerak menerima potensi kehilangan data sebagai pertukaran untuk impak kependaman yang lebih rendah merentasi tapak yang jauh.

1.4 Penyelesaian Sentiasa Terkini

SQL Server Always On menyediakan tiga pilihan penggunaan, setiap satunya sesuai dengan ketersediaan dan keperluan infrastruktur yang berbeza. Panduan ini merangkumi ketiga-tiganya:

Kumpulan Ketersediaan Sentiasa Aktif (AG): Ketersediaan tinggi peringkat pangkalan data dan pemulihan bencana tanpa storan kongsi.
Tika Kluster Kegagalan Sentiasa Aktif (FCI): Ketersediaan tinggi peringkat tika menggunakan storan kongsi.
AG + FCI digabungkan: Perlindungan dua lapisan yang menggabungkan failover peringkat contoh dan peringkat pangkalan data untuk daya tahan maksimum.

2. Kumpulan Ketersediaan Sentiasa Aktif

Kumpulan Ketersediaan Sentiasa Aktif (AG) ialah penyelesaian ketersediaan tinggi dan pemulihan bencana peringkat pangkalan data yang mereplikasi satu set pangkalan data pengguna sehingga lapan replika sekunder melalui penghantaran log transaksi berterusan.

2.1 Ciri Utama

Kegagalan peringkat pangkalan data: pangkalan data atau kumpulan individu boleh gagal secara bebas daripada SQL Server contoh;
sehingga sembilan replika (satu primer, lapan sekunder) dalam Edisi Perusahaan;
mod komit segerak untuk kehilangan data sifar; komit tak segerak untuk replika DR yang jauh;
failover automatik untuk replika segerak apabila yang utama menjadi tidak tersedia;
replika sekunder yang boleh dibaca untuk pemunggahan beban kerja pelaporan dan sandaran;
Pendengar kumpulan ketersediaan menyediakan titik akhir sambungan tunggal yang secara automatik menghala ke primer semasa.

2.2 Langkah-langkah Pelaksanaan

Sediakan akaun perkhidmatan Active Directory dan konfigurasikan kebenaran pada semua nod;
pasang dan sahkan Pengelompokan Failover Windows Server pada semua pelayan yang mengambil bahagian;
memasang SQL Server sebagai contoh kendiri pada setiap nod menggunakan laluan dan tetapan yang konsisten;
dayakan ciri Kumpulan Ketersediaan Sentiasa Aktif melalui SQL Server Pengurus Konfigurasi atau PowerShell;
tetapkan pangkalan data kepada model pemulihan penuh dan buat sandaran penuh dan log;
cipta kumpulan ketersediaan, tambah replika dan konfigurasikan mod ketersediaan dan failover;
replika sekunder benih menggunakan pembenihan automatik atau sandaran dan pemulihan manual;
cipta pendengar kumpulan ketersediaan dan sahkan ketersambungan klien.

Untuk panduan langkah demi langkah yang lengkap, sila lihat Panduan lengkap Kumpulan Ketersediaan Sentiasa Aktif.

2.3 Terbaik Untuk

Pangkalan data misi kritikal yang memerlukan kehilangan data sifar dan failover automatik;
beban kerja yang memerlukan sekunder yang boleh dibaca untuk pelaporan atau penyingkiran sandaran;
penggunaan yang merangkumi pelbagai tapak untuk pemulihan bencana;
persekitaran tanpa infrastruktur storan kongsi sedia ada.

2.4 Kebaikan

Tiada storan kongsi diperlukan — setiap replika menggunakan storan setempat bebas;
menyokong kedua-dua HA dan DR dalam satu konfigurasi;
sekunder yang boleh dibaca mengurangkan beban kerja utama;
Kebutiran peringkat pangkalan data membenarkan dasar failover yang berbeza bagi setiap kumpulan pangkalan data.

2.5 Keburukan

Memerlukan Edisi Perusahaan untuk set ciri penuh (Standard menyokong Basic AG dengan batasan yang ketara);
mod komit segerak menambah latensi tulis berkadaran dengan masa perjalanan pergi balik rangkaian;
log masuk, kerja Ejen SQL dan pelayan yang dipautkan memerlukan penyegerakan manual dalam SQL Server 2019 dan sebelumnya;
semua replika mesti berada pada nod bagi Kluster Failover Windows Server yang sama.

2.6 Rujukan

Dokumen Rasmi Microsoft: Apakah kumpulan ketersediaan Sentiasa Aktif?
Dokumen Rasmi Microsoft: Bermula dengan Kumpulan Ketersediaan Sentiasa Aktif

3. Contoh Kluster Failover Sentiasa Aktif

Tika Kluster Kegagalan Sentiasa Aktif (FCI) menyediakan ketersediaan tinggi peringkat contoh dengan menjalankan satu SQL Server contoh merentasi berbilang nod fizikal yang berkongsi storan yang sama. Apabila nod aktif gagal, SQL Server contoh pada nod siap sedia dimulakan semula secara automatik, menjadikan peralihan telus kepada aplikasi klien.

3.1 Ciri Utama

Kegagalan peringkat contoh: semua pangkalan data pada contoh gagal bersama sebagai satu unit;
storan kongsi (Rangkaian Kawasan Storan (SAN), iSCSI, Storage Spaces Direct atau SMB) yang boleh diakses oleh semua nod;
nama rangkaian maya dan alamat IP maya menyediakan titik akhir sambungan yang stabil tanpa mengira nod mana yang aktif;
Pengelompokan Failover Windows Server mengurus pemantauan kesihatan nod, kuorum dan orkestrasi failover;
menyokong jenis konfigurasi nod Aktif/Bersedia, Aktif/Aktif, N+1 dan N+M.

3.2 Langkah-langkah Pelaksanaan

Sediakan dan lampirkan storan kongsi kepada semua nod kluster;
pasang ciri Failover Clustering dan sahkan konfigurasi kluster;
cipta Kluster Failover Windows Server dan konfigurasikan kuorum;
jalankan SQL Server pemasangan memilih pilihan kluster failover dan menentukan nama rangkaian maya dan laluan storan kongsi;
tambah nod tambahan pada SQL Server tika kluster failover;
sahkan tingkah laku failover dengan menguji failover manual antara nod.

Untuk panduan langkah demi langkah yang lengkap, sila lihat SQL Server Panduan lengkap Kluster Failover.

3.3 Terbaik Untuk

Persekitaran dengan infrastruktur storan kongsi sedia ada (SAN atau iSCSI);
aplikasi yang memerlukan failover peringkat contoh di mana semua pangkalan data mesti gagal bersama-sama;
senario di mana ketelusan pelanggan adalah kritikal dan tiada perubahan dari segi aplikasi boleh diterima;
organisasi yang mengutamakan kesederhanaan model failover satu tika.

3.4 Kebaikan

Kegagalan automatik pada peringkat tika tanpa memerlukan konfigurasi semula klien;
tiada overhed replikasi data — semua nod mengakses storan yang sama;
tingkah laku failover yang boleh diramal untuk semua pangkalan data secara serentak;
menyokong konfigurasi nod fleksibel (Aktif/Aktif, N+1, N+M) untuk mengoptimumkan penggunaan perkakasan.

3.5 Keburukan

Storan kongsi merupakan satu-satunya titik kegagalan yang berpotensi melainkan storan itu sendiri berlebihan;
hanya satu nod yang berjalan SQL Server pada satu masa — tiada pengimbangan beban baca pada nod sekunder;
tiada pemulihan bencana terbina dalam tanpa berpasangan dengan kumpulan ketersediaan;
infrastruktur storan kongsi menambah kos dan kerumitan berbanding AG.

3.6 Rujukan

Dokumen Rasmi Microsoft: Tika Kluster Kegagalan Sentiasa Aktif (SQL Server)

4. Gabungkan Kumpulan Ketersediaan dengan Contoh Kluster Failover

Bagi organisasi yang memerlukan perlindungan peringkat contoh dan peringkat pangkalan data, SQL Server menyokong pengehosan replika kumpulan ketersediaan pada Failover Cluster Instances (FCI). Dalam konfigurasi ini, setiap nod FCI bertindak sebagai replika ketersediaan tunggal, jadi failover FCI adalah telus kepada kumpulan ketersediaan manakala failover AG menyediakan perlindungan peringkat pangkalan data merentasi tapak. Gabungan ini memberikan liputan ketersediaan tinggi dan pemulihan bencana yang paling komprehensif yang tersedia dalam SQL Server.

4.1 Ciri Utama

Kegagalan dua lapisan: FCI mengendalikan kegagalan nod peringkat contoh; AG mengendalikan kegagalan peringkat tapak atau peringkat replika;
setiap FCI dikira sebagai replika tunggal dalam kumpulan ketersediaan tanpa mengira berapa banyak nod yang terkandung dalam FCI;
Replika yang dihoskan oleh FCI masih memerlukan storan kongsi mengikut keperluan FCI standard;
Replika AG yang dihoskan pada FCI hanya menyokong failover manual — failover automatik tidak tersedia untuk replika yang dihoskan oleh FCI;
Tikaan kendiri boleh menyertai kumpulan ketersediaan yang sama bersama replika yang dihoskan oleh FCI.

4.2 Langkah-langkah Pelaksanaan

Gunakan dan sahkan setiap FCI secara bebas mengikut prosedur persediaan FCI standard;
memastikan semua nod FCI dan nod replika kendiri tergolong dalam Kluster Failover Windows Server yang sama;
dayakan ciri Kumpulan Ketersediaan Sentiasa Aktif pada setiap tika FCI;
sahkan bahawa tiada nod WSFC tunggal akan menjadi hos dua replika kumpulan ketersediaan yang sama selepas sebarang kemungkinan kegagalan FCI;
cipta kumpulan ketersediaan, menetapkan tika FCI sebagai replika dan mengkonfigurasi mod failover manual untuk semua replika yang dihoskan oleh FCI;
benih replika sekunder dan konfigurasikan pendengar kumpulan ketersediaan.

Untuk butiran persediaan FCI, lihat SQL Server Panduan lengkap Kluster Failover. Untuk butiran persediaan AG, lihat panduan lengkap Kumpulan Ketersediaan Sentiasa Aktif kami.

4.3 Terbaik Untuk

Persekitaran misi kritikal yang memerlukan perlindungan terhadap kegagalan nod individu dan bencana peringkat tapak;
organisasi yang sudah menjalankan FCI yang perlu menambah pemulihan bencana merentas tapak;
industri yang dikawal selia di mana SLA perlindungan data dan ketersediaan maksimum adalah wajib;
penggunaan berskala besar yang mana dasar failover peringkat contoh dan peringkat pangkalan data mesti wujud bersama.

4.4 Kebaikan

Perlindungan maksimum: kegagalan nod dikendalikan oleh FCI, kegagalan tapak dikendalikan oleh AG;
Kegagalan FCI adalah telus kepada kumpulan ketersediaan — AG tidak melihat perubahan replika semasa kegagalan FCI;
Topologi fleksibel: campurkan replika yang dihoskan oleh FCI dan replika kendiri dalam kumpulan ketersediaan yang sama.

4.5 Keburukan

Replika yang dihoskan oleh FCI hanya menyokong failover AG manual — failover AG automatik tidak tersedia untuk replika ini;
memerlukan perancangan nod WSFC yang teliti untuk mengelakkan satu nod daripada menjadi hos kepada dua replika AG yang sama selepas kegagalan FCI;
kos infrastruktur dan kerumitan operasi yang lebih tinggi berbanding AG atau FCI sahaja;
storan kongsi masih diperlukan untuk setiap komponen FCI.

4.6 Rujukan

Dokumen Rasmi Microsoft: Pengelompokan Failover dan Kumpulan Ketersediaan Sentiasa Aktif (SQL Server)
Dokumen Rasmi Microsoft: Apakah kumpulan ketersediaan Sentiasa Aktif?
Dokumen Rasmi Microsoft: Bermula dengan Kumpulan Ketersediaan Sentiasa Aktif
Dokumen Rasmi Microsoft: Tika Kluster Kegagalan Sentiasa Aktif (SQL Server)

5. Perbandingan Penyelesaian Sentiasa Teraktif

5.1 Jadual Perbandingan Ciri

Ciri	Kumpulan Ketersediaan	Contoh Kluster Failover	Gabungan AG + FCI
Skop kegagalan	Peringkat pangkalan data	Peringkat contoh	Kedua-dua
Storan kongsi diperlukan	Tidak	Ya	Ya (untuk komponen FCI)
Replikasi data	Berasaskan log untuk setiap replika	Tiada (storan kongsi)	Berasaskan log antara FCI
Failover automatik	Ya (replika segerak)	Ya	FCI: Ya; AG: Tidak
Sekunder yang boleh dibaca	Ya	Tidak	Ya (komponen AG)
Pemulihan bencana	Terbina dalam	Tidak terbina dalam	Terbina dalam
Replika maksimum	9 (Perusahaan)	Tidak Berkenaan	9 (Perusahaan)
Kerumitan infrastruktur	sederhana	sederhana	Tinggi
kos	Lebih rendah (SAN tidak diperlukan)	Lebih tinggi (SAN diperlukan)	Tertinggi

5.2 Pilih Penyelesaian Sentiasa Teraktif Anda

Mulakan dengan infrastruktur storan anda: jika anda tidak mempunyai storan kongsi sedia ada, Availability Groups ialah pilihan semula jadi dan laluan paling kos efektif untuk kedua-dua HA dan DR. Jika anda sudah mengendalikan persekitaran SAN dan memerlukan failover peringkat contoh, FCI ialah pilihan yang lebih mudah — tetapi rancang untuk menambah AG kemudian jika DR merentas tapak merupakan keperluan masa hadapan.

Pilih kombinasi AG + FCI hanya apabila anda mempunyai keperluan sebenar untuk kedua-dua lapisan perlindungan dan kematangan operasi untuk menguruskan peningkatan kerumitan. Kekangan utama yang perlu diingat ialah replika AG yang dihoskan oleh FCI tidak menyokong failover AG automatik, jadi topologi ini memerlukan intervensi manual untuk failover peringkat kumpulan ketersediaan.

Bagi kebanyakan penggunaan greenfield hari ini, Always On Availability Groups ialah titik permulaan yang disyorkan: ia merangkumi kedua-dua HA dan DR, tidak memerlukan storan kongsi dan menyokong sekunder yang boleh dibaca — keupayaan yang tidak dapat ditandingi oleh FCI sahaja.

6. Amalan Terbaik untuk SQL Server Penyelesaian Sentiasa Terkini

6.1 Perancangan dan Reka Bentuk

Takrifkan keperluan RTO dan RPO sebelum memilih penyelesaian Sentiasa Aktif — sasaran ini secara langsung menentukan sama ada mod komit segerak atau tak segerak sesuai dan sama ada failover automatik boleh dilaksanakan.
Saiz replika sekunder untuk mengendalikan beban kerja utama penuh semasa peristiwa failover, termasuk senario beban puncak.
Untuk penggunaan AG, letakkan replika segerak dalam pusat data yang sama atau rangkaian latensi rendah untuk meminimumkan kesan latensi penulisan. Tempah mod tak segerak untuk replika DR yang jauh secara geografi.
Kuorum reka bentuk dengan bilangan undian ganjil. Untuk kluster dua nod, tambahkan perkongsian fail atau saksi awan sebagai undian ketiga untuk mengelakkan senario otak berpecah.
Rancang topologi rangkaian anda dengan teliti untuk penggunaan berbilang subnet. Setiap subnet memerlukan alamat IP pendengarnya sendiri dan klien memerlukan MultiSubnetFailover=True dalam rentetan sambungan mereka.

6.2 Garis Panduan Pelaksanaan

Gunakan secara konsisten SQL Server tahap versi, edisi dan kemas kini kumulatif merentasi semua replika. Tahap tampalan campuran boleh menyebabkan tingkah laku yang tidak dijangka semasa failover.
Konfigurasikan antara muka rangkaian khusus untuk trafik degupan jantung kluster, berasingan daripada trafik aplikasi.
Dayakan pembenihan automatik untuk penyegerakan pangkalan data awal dalam SQL Server 2016 dan kemudian — ia menghapuskan keperluan untuk menyalin sandaran secara manual ke replika sekunder untuk kebanyakan senario.
Untuk topologi AG + FCI, sahkan selepas setiap perubahan konfigurasi nod FCI bahawa tiada nod WSFC tunggal yang boleh menjadi hos dua replika kumpulan ketersediaan yang sama.
Sentiasa gunakan SQL Server Studio Pengurusan atau Transact-SQL untuk mengurus failover kumpulan ketersediaan — jangan sekali-kali menggunakan Pengurus Kluster Failover secara langsung, kerana ia tidak menyedari keadaan penyegerakan AG dan boleh menyebabkan masa henti yang berpanjangan atau kehilangan data.

6.3 Pemantauan dan Penyelenggaraan

Pantau kesihatan penyegerakan, hantar giliran dan buat semula giliran secara berkala menggunakan papan pemuka kumpulan ketersediaan dalam SQL Server Studio Pengurusan atau Pandangan Pengurusan Dinamik (DMV). Giliran redo yang semakin meningkat pada sekunder menunjukkan kesesakan I/O yang akan melambatkan pemulihan failover.
Jalankan DBCC CHECKDB pada replika sekunder untuk memindahkan semakan integriti daripada replika utama. Lihat Panduan DBCC CHECKDB untuk maklumat lanjut.
Memohon SQL Server tampalan menggunakan naik taraf bergilir: tampalan replika sekunder terlebih dahulu, lakukan failover manual yang dirancang kepada sekunder yang ditampal, kemudian tampalan primer sebelumnya. Ini mengehadkan masa henti kepada tempoh failover tunggal.
Uji failover secara berkala dalam persekitaran bukan pengeluaran. Failover automatik yang tidak pernah diuji bukanlah strategi pemulihan yang boleh dipercayai.
Konfigurasikan makluman untuk perubahan keadaan kesihatan kumpulan ketersediaan, peralihan peranan replika dan kegagalan penyegerakan menggunakan SQL Server Ejen atau alat pemantauan khusus seperti SQL Server Monitor Prestasi.

7. Soalan Lazim

Q: Apa itu SQL Server Sentiasa Hidup?

A: SQL Server Always On ialah platform ketersediaan tinggi dan pemulihan bencana Microsoft yang diperkenalkan pada SQL Server 2012. Ia merangkumi dua teknologi — Kumpulan Ketersediaan Sentiasa Aktif dan Tika Kluster Failover Sentiasa Aktif — yang menyediakan failover automatik, redundansi data dan akses berterusan ke pangkalan data sekiranya berlaku kegagalan perkakasan, perisian atau tapak.

S: Apakah perbezaan antara Kumpulan Ketersediaan Sentiasa Aktif dan Tika Kluster Failover?

A: Kumpulan Ketersediaan beroperasi pada peringkat pangkalan data, mereplikasi data kepada replika sekunder bebas melalui penghantaran log dan tidak memerlukan storan kongsi. Tika Kluster Failover beroperasi pada peringkat tika, memerlukan storan kongsi yang boleh diakses oleh semua nod dan gagal merentasi semua pangkalan data bersama-sama sebagai satu unit. AG menyokong sekunder yang boleh dibaca dan DR terbina dalam; FCI tidak.

S: Adakah saya memerlukan storan kongsi untuk Kumpulan Ketersediaan Sentiasa Aktif?

A: Tidak. Setiap replika AG mengekalkan salinan pangkalan data bebasnya sendiri pada storan setempat. Storan kongsi hanya diperlukan jika anda menggunakan Failover Cluster Instances untuk mengehoskan replika AG.

S: Bolehkah saya menggunakan Sentiasa Hidup dengan SQL Server Edisi Standard?

A: SQL Server Edisi Standard menyokong Kumpulan Ketersediaan Asas bermula dengan SQL Server 2016, tetapi dengan batasan yang ketara: satu pangkalan data bagi setiap AG, maksimum dua replika dan tiada sokongan sekunder yang boleh dibaca. FCI tersedia dalam Edisi Standard tanpa sekatan ini. Edisi Perusahaan diperlukan untuk fungsi Sentiasa Aktif sepenuhnya.

S: Berapakah bilangan maksimum replika dalam kumpulan ketersediaan?

A: SQL Server Edisi Perusahaan menyokong sehingga sembilan replika: satu primer dan lapan sekunder. Kumpulan ketersediaan teragih boleh melanjutkan ini kepada 18 replika merentasi dua kumpulan ketersediaan berasingan.

S: Bolehkah replika yang dihoskan oleh FCI menggunakan failover AG automatik?

A: Tidak. Apabila replika ketersediaan dihoskan pada Tika Kluster Failover, failover kumpulan ketersediaan automatik tidak disokong untuk replika tersebut. Semua failover AG yang melibatkan replika yang dihoskan oleh FCI memerlukan intervensi manual.

S: Apakah perbezaan antara mod komit segerak dan tak segerak?

A: Mod komit segerak memerlukan primer menunggu sekunder mengeraskan rekod log sebelum melakukan komit, memastikan kehilangan data sifar (RPO = 0) dengan kos latensi penulisan tambahan. Mod komit tak segerak membolehkan primer melakukan komit tanpa menunggu, mengurangkan latensi tetapi berisiko kehilangan data jika primer gagal sebelum sekunder menerima semua rekod log. Gunakan segerak untuk replika HA tempatan dan tak segerak untuk replika DR jauh.

S: Berapa lamakah a SQL Server Pengambilan failover Sentiasa Aktif?

A: Kegagalan automatik untuk replika AG segerak biasanya selesai dalam masa kurang daripada 30 saat dalam keadaan biasa. Kegagalan FCI biasanya mengambil masa 20–60 saat bergantung pada masa pemulihan pangkalan data. Tempoh sebenar bergantung pada beban kerja, saiz pangkalan data dan tetapan tamat masa semakan kesihatan yang dikonfigurasikan dalam WSFC.

S: Apa yang berlaku kepada sambungan klien semasa failover?

A: Sambungan sedia ada akan digugurkan apabila failover berlaku. Aplikasi yang menggunakan pendengar kumpulan ketersediaan dan termasuk logik percubaan semula sambungan akan menyambung semula secara automatik ke primer baharu selepas failover selesai. Menambah MultiSubnetFailover=True to connection strings akan meningkatkan kelajuan penyambungan semula dalam penggunaan berbilang subnet.

S: Bagaimanakah saya boleh memohon SQL Server tampalan dengan masa henti minimum dalam persekitaran Sentiasa Aktif?

A: Gunakan peningkatan bergilir: tampal replika sekunder terlebih dahulu, kemudian lakukan failover manual yang dirancang pada sekunder yang ditampal, dan akhirnya tampal primer sebelumnya. Ini mengehadkan masa henti kepada tempoh failover yang dirancang tunggal — biasanya kurang daripada seminit.

S: Bolehkah saya menggabungkan Kumpulan Ketersediaan Sentiasa Aktif dengan Tika Kluster Failover?

J: Ya. Anda boleh mengehos replika AG pada tika FCI untuk mencapai perlindungan failover peringkat tika dan pangkalan data. Setiap FCI dikira sebagai replika AG tunggal. Topologi ini memerlukan perancangan nod WSFC yang teliti untuk memastikan tiada nod tunggal yang mengehos dua replika AG yang sama selepas sebarang kemungkinan failover FCI.

S: Apakah yang perlu saya lakukan jika pangkalan data saya rosak dalam persekitaran Sentiasa Aktif?

A: Pertama, periksa sama ada kerosakan wujud pada semua replika atau hanya replika utama. Jika kerosakan sekunder wujud, segera alihkan ke replika tersebut. Untuk kerosakan pada semua replika, pulihkan daripada sandaran yang bersih. Jalankan DBCC CHECKDB pada replika sekunder secara berkala untuk mengesan kerosakan lebih awal. Jika sandaran juga terjejas, pakar khusus SQL Server alat pemulihan data boleh cuba mengekstrak data daripada fail MDF yang rosak sebagai pilihan terakhir.

S: Bagaimanakah Kumpulan Ketersediaan Sentiasa Aktif berbanding dengan yang lebih lama SQL Server Penyelesaian HA?

A: AG menggantikan teknologi lama seperti penghantaran balak dan replikasiPenghantaran log memerlukan failover manual dan tiada peralihan peranan automatik; replikasi direka bentuk untuk pengedaran data dan bukannya HA. AG memberikan failover automatik, kehilangan data sifar dengan komit segerak dan sekunder yang boleh dibaca — keupayaan yang tidak dapat ditandingi oleh teknologi tersebut.

8. kesimpulan

SQL Server Always On menyediakan platform gred perusahaan yang fleksibel untuk ketersediaan tinggi dan pemulihan bencana. Always On Availability Groups ialah pilihan yang tepat untuk kebanyakan penggunaan moden: ia menghapuskan keperluan untuk storan kongsi, menyokong sekunder yang boleh dibaca dan mengendalikan kedua-dua HA tempatan dan DR merentas tapak dalam konfigurasi tunggal. Contoh Kluster Failover kekal sebagai pilihan yang kukuh apabila failover peringkat contoh dan infrastruktur storan kongsi sedia ada merupakan keperluan utama. Menggabungkan kedua-dua teknologi memberikan perlindungan terdalam yang tersedia — dengan kos pelaburan infrastruktur yang lebih besar dan kerumitan operasi.

Walau apa pun penyelesaian yang anda pilih, asasnya adalah sama: tentukan keperluan RTO dan RPO anda terlebih dahulu, reka bentuk topologi anda berdasarkan sasaran tersebut dan uji failover secara berkala. Penyelesaian Sentiasa Aktif yang dilaksanakan dengan baik dan telah diuji secara menyeluruh akan pulih seperti yang dijangka apabila kegagalan pengeluaran berlaku.

Mengenai Penulis

Yuan Sheng ialah pentadbir pangkalan data kanan (DBA) dengan lebih 10 tahun pengalaman dalam SQL Server persekitaran dan pengurusan pangkalan data perusahaan. Beliau telah berjaya menyelesaikan ratusan senario pemulihan pangkalan data merentas perkhidmatan kewangan, penjagaan kesihatan dan organisasi pembuatan.

Yuan pakar dalam SQL Server pemulihan pangkalan data, penyelesaian ketersediaan tinggi dan pengoptimuman prestasi. Pengalaman praktikalnya yang luas termasuk mengurus pangkalan data berbilang terabait, melaksanakan Kumpulan Ketersediaan Sentiasa Dihidupkan, dan membangunkan strategi sandaran dan pemulihan automatik untuk sistem perniagaan yang kritikal misi.

Melalui kepakaran teknikal dan pendekatan praktikalnya, Yuan menumpukan pada mencipta panduan komprehensif yang membantu pentadbir pangkalan data dan profesional IT menyelesaikan kompleks SQL Server cabaran dengan cekap. Dia kekal terkini dengan yang terkini SQL Server keluaran dan teknologi pangkalan data Microsoft yang sedang berkembang, menguji senario pemulihan secara kerap untuk memastikan cadangannya mencerminkan amalan terbaik dunia sebenar.

Ada soalan tentang SQL Server pemulihan atau memerlukan panduan penyelesaian masalah pangkalan data tambahan? Yuan mengalu-alukan maklum balas dan cadangan untuk menambah baik sumber teknikal ini.