SQL Server Doim yoqilgan: DBA uchun to'liq qo'llanma [2026]

SQL Server Always On - bu Microsoft tomonidan taqdim etilgan keng qamrovli yuqori darajadagi mavjudlik va favqulodda vaziyatlardan keyin tiklanish yechimi. SQL Server 2012. Bu ma'lumotlar bazasini aks ettirish va jurnallarni jo'natish kabi oldingi texnologiyalarga nisbatan sezilarli yutuqni ifodalaydi, bu esa ma'lumotlarga uzluksiz kirishni ta'minlaydi, shu bilan birga ishlamay qolish vaqtini va ma'lumotlar yo'qotilishini minimallashtiradi.

1.2 Nima uchun bizneslar doimo yechimlarga muhtoj

Bugungi raqamli iqtisodiyotda ma'lumotlar bazasining ishlamay qolishi to'g'ridan-to'g'ri l ga aylanadiost daromad, buzilgan obro' va tartibga solishga muvofiqlik muammolari. Tashkilotlar turli xil nosozlik stsenariylaridan himoya qilish bilan birga deyarli uzluksiz ishlashni kafolatlaydigan yuqori darajadagi mavjudlik yechimlarini talab qiladi.

An'anaviy zaxira nusxalash va tiklash protseduralari zamonaviy biznes talablari uchun yetarli emas. Muhim ma'lumotlar bazasi ishlamay qolganda, biznes zaxira nusxalaridan tiklash uchun zarur bo'lgan soatlarni to'lay olmaydi. Always On yechimlari tizimdagi nosozliklar ta'sirini sezilarli darajada kamaytiradigan, xizmatni soatlab emas, balki soniyalar yoki daqiqalarda tiklaydigan avtomatlashtirilgan ishdan chiqishni ta'minlaydi.

Asosiy mavjudlikdan tashqari, bizneslar ishlab chiqarish ma'lumotlar bazalaridan o'qish uchun ko'p vaqt talab qiladigan ish yuklamalarini olib tashlashlari, uzilishlarsiz texnik xizmat ko'rsatishlari va sayt darajasidagi ofatlardan himoyalanishlari kerak. SQL Server Always On ushbu talablarning barchasini kichik joylashtirishlardan tortib global miqyosda taqsimlangan tizimlargacha bo'lgan yagona arxitektura orqali qondiradi.

1.3 Asosiy tushunchalar: RTO, RPO, HA va DR

Qayta tiklash vaqti maqsadi (RTO) nosozlikdan keyin ishlamay qolishning maksimal maqbul davomiyligini belgilaydi - ma'lumotlar bazasi qanchalik tez qayta ishga tushishi kerak.

Qayta tiklash nuqtasi maqsadi (RPO) vaqt bilan o'lchanadigan maksimal maqbul ma'lumotlar yo'qotilishini belgilaydi - biznes yaqinda berilgan ma'lumotlarning qanchasini yo'qotishga qodir.

Yuqori mavjudlik (HA) bir xil ma'lumotlar markazida apparat nosozliklari yoki dasturiy ta'minotning ishdan chiqishi kabi muntazam nosozliklar tufayli yuzaga keladigan uzilish vaqtini minimallashtirishga qaratilgan.

Tabiiy ofatdan tiklash (DR) butun saytlarga ta'sir qiluvchi halokatli hodisalarni bartaraf etadi, ma'lumotlar nusxalarini geografik jihatdan alohida joylarda saqlaydi. HA ishlamay qolish vaqtini minimallashtirishga e'tibor qaratsa, DR yirik hodisalar paytida ma'lumotlarni himoya qilish va biznesning uzluksizligini ta'minlashga e'tibor qaratadi.

SQL Server Always On yagona birlashtirilgan arxitektura doirasida HA va DR ni qo'llab-quvvatlaydi. Sinxron-kommit rejimi nolga yaqin RTO uchun avtomatik almashtirish bilan RPO = 0 ni ta'minlaydi; asinxron-kommit rejimi uzoq joylarda kechikish ta'sirini kamaytirish evaziga ma'lumotlar yo'qotilishini qabul qiladi.

1.4 Doim Yoqimli Yechimlar

SQL Server Always On uchta joylashtirish variantini taqdim etadi, ularning har biri turli xil mavjudlik va infratuzilma talablariga mos keladi. Ushbu qo'llanma uchta variantni ham qamrab oladi:

Doim mavjud guruhlar (AG): Ma'lumotlar bazasi darajasidagi yuqori mavjudlik va umumiy saqlashsiz favqulodda vaziyatlardan tiklanish.
Doim yoqilgan xatolik klasteri misollari (FCI): Umumiy saqlashdan foydalangan holda namunaviy darajadagi yuqori mavjudlik.
AG + FCI birlashtirilgan: Maksimal chidamlilik uchun instansiya darajasidagi va ma'lumotlar bazasi darajasidagi ishdan chiqishni birlashtirgan ikki qatlamli himoya.

2. Doim mavjud guruhlar

Doim mavjud guruhlar (AG) ma'lumotlar bazasi darajasidagi yuqori darajadagi mavjudlik va falokatdan keyin tiklanish yechimi bo'lib, u foydalanuvchi ma'lumotlar bazalari to'plamini uzluksiz tranzaksiyalar jurnalini yetkazib berish orqali sakkiztagacha ikkilamchi replikalarga ko'paytiradi.

2.1 Asosiy xususiyatlar

Ma'lumotlar bazasi darajasidagi ishdan chiqish: alohida ma'lumotlar bazalari yoki guruhlar mustaqil ravishda ishdan chiqishi mumkin SQL Server misol;
Enterprise Edition’da to‘qqiztagacha nusxalar (bitta asosiy, sakkizta ikkilamchi);
nol ma'lumotlar yo'qotilishi uchun sinxron-kommit rejimi; uzoqdagi DR replikalari uchun asinxron-kommit rejimi;
birlamchi mavjud bo'lmaganda sinxron nusxalar uchun avtomatik ravishda ishdan chiqish;
hisobotlarni tushirish va ish yuklamalarini zaxiralash uchun o'qilishi mumkin bo'lgan ikkilamchi nusxalar;
mavjudlik guruhi tinglovchisi avtomatik ravishda joriy asosiy qurilmaga yo'naltiriladigan bitta ulanish nuqtasini taqdim etadi.

2.2 Amalga oshirish bosqichlari

Active Directory xizmat hisoblarini tayyorlang va barcha tugunlarda ruxsatnomalarni sozlang;
barcha ishtirok etuvchi serverlarda Windows Server Failover Clustering-ni o'rnatish va tasdiqlash;
o'rnatish SQL Server izchil yo'llar va sozlamalardan foydalangan holda har bir tugunda mustaqil misol sifatida;
Doim faol bo'lgan mavjudlik guruhlari funksiyasini yoqish orqali SQL Server Konfiguratsiya menejeri yoki PowerShell;
ma'lumotlar bazalarini to'liq tiklash modeliga o'rnatish va to'liq va jurnal zaxira nusxalarini olish;
mavjudlik guruhini yarating, nusxalarni qo'shing va mavjudlik va ishlamay qolish rejimlarini sozlang;
avtomatik ekish yoki qo'lda zaxiralash va tiklash yordamida ikkilamchi replikalarni ekish;
Mavjudlik guruhi tinglovchisini yarating va mijoz ulanishini tekshiring.

To'liq bosqichma-bosqich ko'rsatmalar uchun bizning sahifamizga qarang Doim mavjud guruhlar uchun to'liq qo'llanma.

2.3 Eng yaxshisi

Nol ma'lumotlar yo'qotilishi va avtomatik ravishda ishdan chiqishni talab qiladigan muhim ma'lumotlar bazalari;
hisobot berish yoki zaxira nusxasini tushirish uchun o'qilishi mumkin bo'lgan ikkilamchi fayllarni talab qiladigan ish yuklamalari;
tabiiy ofatlardan keyin tiklanish uchun bir nechta joylarni qamrab oluvchi joylashtirishlar;
mavjud umumiy saqlash infratuzilmasi bo'lmagan muhitlar.

2.4 tarozi

Umumiy saqlash joyi talab qilinmaydi — har bir nusxa mustaqil mahalliy saqlash joyidan foydalanadi;
bitta konfiguratsiyada HA va DR ni qo'llab-quvvatlaydi;
o'qilishi mumkin bo'lgan ikkilamchi fayllar asosiy ish yukini kamaytiradi;
ma'lumotlar bazasi darajasidagi aniqlik har bir ma'lumotlar bazasi guruhi uchun turli xil ishdan chiqish siyosatlarini amalga oshirish imkonini beradi.

2.5 Kamchiliklari

To'liq funksiyalar to'plami uchun Enterprise Edition talab qilinadi (Standard muhim cheklovlar bilan Basic AG ni qo'llab-quvvatlaydi);
sinxron-kommit rejimi yozish kechikishini tarmoqning aylanish vaqtiga mutanosib ravishda qo'shadi;
loginlar, SQL Agent vazifalari va bog'langan serverlar qo'lda sinxronizatsiyani talab qiladi SQL Server 2019 va undan oldingi yillar;
barcha replikalar bir xil Windows Server Failover klasterining tugunlarida joylashgan bo'lishi kerak.

2.6 Adabiyotlar

Microsoft rasmiy hujjati: Doim yoqilgan mavjudlik guruhi nima?
Microsoft rasmiy hujjati: S ni olishtarDoim yoqilgan mavjudlik guruhlari bilan hamkorlikda

3. Har doim ishlamay qoladigan klaster misollari

Doim ishlamay qoladigan klaster misollari (FCI) bitta ishga tushirish orqali namunaviy darajadagi yuqori mavjudlikni ta'minlaydi SQL Server bir xil xotirani ulashadigan bir nechta jismoniy tugunlar orqali misol. Faol tugun ishlamay qolganda, SQL Server kutish tugunidagi misol avtomatik ravishda qayta ishga tushiriladitarted, mijoz ilovalari uchun o'tishni shaffof qiladi.

3.1 Asosiy xususiyatlar

Instansiya darajasidagi ishlamay qolish: instansiyadagi barcha ma'lumotlar bazalari bitta birlik sifatida birgalikda ishlamay qoladi;
barcha tugunlar kirishi mumkin bo'lgan umumiy saqlash (Storage Area Network (SAN), iSCSI, Storage Spaces Direct yoki SMB);
virtual tarmoq nomi va virtual IP-manzil qaysi tugun faol bo'lishidan qat'i nazar, barqaror ulanish nuqtasini ta'minlaydi;
Windows Server Failover Clustering tugunlarning holatini monitoring qilish, kvorum va ishlamay qolishni boshqarishni boshqaradi;
Active/Standby, Active/Active, N+1 va N+M tugun konfiguratsiya turlarini qo'llab-quvvatlaydi.

3.2 Amalga oshirish bosqichlari

Barcha klaster tugunlariga umumiy xotirani taqdim etish va ulash;
Failover Clustering funksiyasini o'rnating va klaster konfiguratsiyasini tasdiqlang;
Windows Server Failover klasterini yarating va kvorumni sozlang;
boshqaring SQL Server o'rnatish, ishdan chiqish klasteri opsiyasini tanlash va virtual tarmoq nomi va umumiy saqlash yo'llarini belgilash;
qo'shimcha tugunlarni qo'shing SQL Server ishlamay qolgan klaster misoli;
tugunlar o'rtasida qo'lda bajariladigan ishdan chiqishni sinab ko'rish orqali ishdan chiqish xatti-harakatlarini tekshiring.

To'liq bosqichma-bosqich ko'rsatmalar uchun bizning sahifamizga qarang SQL Server Failover Cluster to'liq qo'llanmasi.

3.3 Eng yaxshisi

Mavjud umumiy saqlash infratuzilmasiga (SAN yoki iSCSI) ega muhitlar;
barcha ma'lumotlar bazalari birgalikda ishdan chiqishi kerak bo'lgan instansiya darajasidagi ishdan chiqishni talab qiladigan ilovalar;
mijoz shaffofligi juda muhim bo'lgan va dastur tomonidan hech qanday o'zgartirishlar qabul qilinmaydigan stsenariylar;
tashkilotlar bitta nusxali ishdan chiqish modelining soddaligiga ustuvor ahamiyat berishadi.

3.4 tarozi

Mijozni qayta konfiguratsiya qilish talab qilinmasdan, instansiya darajasida avtomatik ravishda ishdan chiqish;
ma'lumotlarni replikatsiya qilish uchun ortiqcha yuk yo'q — barcha tugunlar bir xil xotiraga kirish huquqiga ega;
barcha ma'lumotlar bazalari uchun bir vaqtning o'zida oldindan aytib bo'ladigan ishlamay qolish xatti-harakati;
apparatdan foydalanishni optimallashtirish uchun moslashuvchan tugun konfiguratsiyalarini (Active/Active, N+1, N+M) qo'llab-quvvatlaydi.

3.5 Kamchiliklari

Agar saqlashning o'zi ortiqcha bo'lmasa, umumiy saqlash bitta nosozlik nuqtasi bo'lishi mumkin;
faqat bitta tugun ishlaydi SQL Server bir vaqtning o'zida — ikkilamchi tugunlarda o'qish yukini muvozanatlashning yo'qligi;
mavjudlik guruhi bilan bog'lanmasdan, o'rnatilgan favqulodda vaziyatlarni tiklash imkoniyati yo'q;
umumiy saqlash infratuzilmasi c ni qo'shadiost va AG bilan solishtirganda murakkablik.

3.6 Adabiyotlar

Microsoft rasmiy hujjati: Doim ishlamay qoladigan klaster misollari (SQL Server)

4. Mavjudlik guruhlarini ishlamay qolgan klaster misollari bilan birlashtiring

Instansiya darajasida ham, ma'lumotlar bazasi darajasida ham himoya talab qiladigan tashkilotlar uchun, SQL Server h ni qo'llab-quvvatlaydiostFailover Cluster Instances (FCI) da mavjudlik guruhi replikalarini yaratish. Ushbu konfiguratsiyada har bir FCI tuguni bitta mavjudlik replikasi sifatida ishlaydi, shuning uchun FCI ishdan chiqishi mavjudlik guruhi uchun shaffof bo'ladi, AG ishdan chiqishi esa saytlar bo'ylab ma'lumotlar bazasi darajasidagi himoyani ta'minlaydi. Bu kombinatsiya m ni ta'minlaydi.ost keng qamrovli yuqori darajadagi mavjudlik va falokatlardan keyin tiklanish qamrovi mavjud SQL Server.

4.1 Asosiy xususiyatlar

Ikki qavatli ishdan chiqish: FCI instansiya darajasidagi tugun nosozliklarini hal qiladi; AG sayt darajasidagi yoki replika darajasidagi nosozliklarni hal qiladi;
har bir FCI, FCI nechta tugunni o'z ichiga olishidan qat'i nazar, mavjudlik guruhidagi bitta nusxa sifatida hisoblanadi;
FCI-hosttahrirlangan nusxalar hali ham standart FCI talablariga muvofiq umumiy saqlashni talab qiladi;
AG nusxalari hostfaqat FCI qo'llab-quvvatlashida tahrirlangan - FCI-h uchun avtomatik almashtirish mavjud emasosttahrirlangan nusxalar;
mustaqil misollar FCI-h bilan bir xil mavjudlik guruhida ishtirok etishi mumkinosttahrirlangan nusxalar.

4.2 Amalga oshirish bosqichlari

Har bir FCI ni standart FCI o'rnatish tartib-qoidalariga muvofiq mustaqil ravishda joylashtiring va tasdiqlang;
barcha FCI tugunlari va mustaqil replika tugunlari bir xil Windows Server Failover klasteriga tegishli ekanligiga ishonch hosil qiling;
har bir FCI misolida Doim Yoqilgan Mavjudlik Guruhlari funksiyasini yoqish;
hech qanday WSFC tugunining ishlamasligini tekshiringost har qanday mumkin bo'lgan FCI ishdan chiqqanidan keyin bir xil mavjudlik guruhining ikkita nusxasi;
FCI nusxalarini replikalar sifatida belgilab, barcha FCI-h uchun qo'lda o'chirish rejimini sozlab, mavjudlik guruhini yarating.osttahrirlangan nusxalar;
ikkilamchi replikalarni joylashtiring va mavjudlik guruhi tinglovchisini sozlang.

FCI sozlamalari haqida batafsil ma'lumot olish uchun bizning sahifamizga qarang SQL Server Failover Cluster to'liq qo'llanmasi. AG sozlamalari tafsilotlari uchun bizning Doim Yoqimli Availability Groups to'liq qo'llanmasiga qarang.

4.3 Eng yaxshisi

Alohida tugunlarning ishdan chiqishi va sayt darajasidagi ofatlardan himoya talab qiladigan muhim muhitlar;
allaqachon FCIni boshqaradigan va saytlararo falokatlarni tiklashni qo'shishi kerak bo'lgan tashkilotlar;
maksimal ma'lumotlarni himoya qilish va mavjudlik SLAlari majburiy bo'lgan tartibga solingan sohalar;
misol darajasidagi va ma'lumotlar bazasi darajasidagi ishdan chiqish siyosati birgalikda mavjud bo'lishi kerak bo'lgan keng ko'lamli joylashtirishlar.

4.4 tarozi

Maksimal himoya: tugunning ishdan chiqishi FCI tomonidan, saytdagi ishdan chiqishi esa AG tomonidan hal qilinadi;
FCI ishdan chiqishi mavjudlik guruhi uchun shaffofdir — AG FCI ishdan chiqishi paytida hech qanday nusxa o'zgarishini ko'rmaydi;
moslashuvchan topologiya: aralash FCI-hostbir xil mavjudlik guruhidagi tahrirlangan va mustaqil nusxalar.

4.5 Kamchiliklari

FCI-hosted replikalari faqat qo'lda AG ishdan chiqishini qo'llab-quvvatlaydi — bu replikalar uchun avtomatik AG ishdan chiqishi mavjud emas;
bitta tugunning h dan qochishi uchun WSFC tugunini ehtiyotkorlik bilan rejalashtirishni talab qiladiostFCI ishdan chiqqanidan keyin bir xil AG ning ikkita nusxasini olish;
yuqori infratuzilma cost va faqat AG yoki FCI ga qaraganda operatsion murakkablik;
har bir FCI komponenti uchun hali ham umumiy saqlash talab qilinadi.

4.6 Adabiyotlar

Microsoft rasmiy hujjati: Failover klasterlash va doimo mavjudlik guruhlari (SQL Server)
Microsoft rasmiy hujjati: Doim yoqilgan mavjudlik guruhi nima?
Microsoft rasmiy hujjati: S ni olishtarDoim yoqilgan mavjudlik guruhlari bilan hamkorlikda
Microsoft rasmiy hujjati: Doim ishlamay qoladigan klaster misollari (SQL Server)

5. Doim yoqilgan yechimlarni taqqoslash

5.1 Xususiyatlarni taqqoslash jadvali

xususiyati	Mavjudlik guruhlari	Failover klaster misollari	AG + FCI kombinatsiyasi
Ishdan chiqish doirasi	Ma'lumotlar bazasi darajasida	Instance-darajasi	har ikkala
Umumiy saqlash joyi talab qilinadi	Yo'q	ha	Ha (FCI komponenti uchun)
Ma'lumotlarni replikatsiya qilish	Har bir replikaga asoslangan jurnal	Yo'q (umumiy xotira)	FCIlar orasidagi logga asoslangan
Avtomatik uzilish	Ha (sinxron nusxalar)	ha	FCI: Ha; AG: Yo'q
O'qiladigan ikkilamchi ma'lumotlar	ha	Yo'q	Ha (AG komponenti)
Tabiiy ofatlarni tiklash	Ichki o'rnatilgan	O'rnatilgan emas	Ichki o'rnatilgan
Maksimal nusxalar	9 (Korxona)	N / A	9 (Korxona)
Infratuzilmaning murakkabligi	o'rta	o'rta	baland
Cost	Pastroq (SAN kerak emas)	Oliy (SAN talab qilinadi)	eng yuqori

5.2 Doim yoniq bo'lgan yechimingizni tanlang

StarSaqlash infratuzilmangiz bilan: agar sizda mavjud umumiy xotira bo'lmasa, Mavjudlik guruhlari tabiiy tanlovdir va most cost- HA va DR ga samarali yo'l. Agar siz allaqachon SAN muhitini boshqarayotgan bo'lsangiz va namunaviy darajadagi o'chirishga muhtoj bo'lsangiz, FCI oddiyroq variant hisoblanadi - lekin agar kelajakda saytlararo DR talab bo'lsa, keyinchalik AG qo'shishni rejalashtiring.

AG + FCI kombinatsiyasini faqat murakkablikning ortib borishini boshqarish uchun himoya qatlamlari va operatsion yetuklikka chinakam ehtiyoj sezganingizda tanlang. Esda tutish kerak bo'lgan asosiy cheklov shundaki, FCI-hosted AG replikalari AG ning avtomatik ishdan chiqishini qo'llab-quvvatlamaydi, shuning uchun bu topologiya guruh darajasidagi ishdan chiqishlar uchun qo'lda aralashuvni talab qiladi.

m uchunost bugungi kunda yashil maydonlarda joylashtirish, Doim mavjud bo'lgan guruhlar tavsiya etiladitarnuqta: u HA va DR ni ham qamrab oladi, umumiy saqlashni talab qilmaydi va o'qiladigan ikkilamchi qurilmalarni qo'llab-quvvatlaydi - FCI ning o'zi bunga erisha olmaydigan imkoniyatlar.

6. uchun eng yaxshi amaliyotlar SQL Server Doim Yoqimli Yechimlar

6.1 Rejalashtirish va loyihalash

Doim yoqilgan yechimni tanlashdan oldin RTO va RPO talablarini aniqlang — bular tarsinxron yoki asinxron kompilyatsiya rejimi mos keladimi yoki yo'qligini va avtomatik ravishda ishdan chiqishni amalga oshirish mumkinligini to'g'ridan-to'g'ri aniqlaydi.
Eng yuqori yuklanish stsenariylarini o'z ichiga olgan holda, ishdan chiqish hodisasi paytida to'liq asosiy ish yukini boshqarish uchun ikkilamchi replikalarning o'lchamlarini o'zgartiring.
AG joylashtirishlari uchun yozish kechikishiga ta'sirni minimallashtirish uchun sinxron nusxalarni bir xil ma'lumotlar markaziga yoki past kechikishli tarmoqqa joylashtiring. Geografik jihatdan uzoq DR nusxalari uchun asinxron rejimni zaxiralang.
Toq sonli ovozlar bilan kvorumni loyihalash. Ikki tugunli klasterlar uchun miyaning bo'linishi stsenariylarining oldini olish uchun uchinchi ovoz sifatida fayl almashish yoki bulutli guvohni qo'shing.
Ko'p tarmoqli joylashtirish uchun tarmoq topologiyangizni diqqat bilan rejalashtiring. Har bir tarmoq o'zining tinglovchi IP-manzilini talab qiladi va mijozlar ulanish satrlarida MultiSubnetFailover=True ni talab qiladi.

6.2 Amalga oshirish bo'yicha ko'rsatmalar

Izchil foydalaning SQL Server barcha replikalar bo'yicha versiya, nashr va kümülatif yangilanish darajalari. Aralash patch darajalari ishlamay qolish paytida kutilmagan xatti-harakatlarga olib kelishi mumkin.
Klaster yurak urish tezligi trafigi uchun maxsus tarmoq interfeyslarini dastur trafigidan alohida sozlang.
Dastlabki ma'lumotlar bazasi sinxronizatsiyasi uchun avtomatik ekishni yoqish SQL Server 2016 va undan keyingi versiyalar — bu zaxira nusxalarini ikkilamchi nusxalarga qo'lda nusxalash zaruratini yo'q qiladiost stsenariylari.
AG + FCI topologiyalari uchun har bir FCI tugun konfiguratsiyasi o'zgarganda, bitta WSFC tugunining tugamasligini tekshiring.ostbir xil mavjudlik guruhining ikkita nusxasini olish.
Har doim foydalaning SQL Server Mavjudlik guruhidagi nosozliklarni boshqarish uchun Management Studio yoki Transact-SQL dan foydalaning — hech qachon Failover Cluster Manager dan to'g'ridan-to'g'ri foydalanmang, chunki u AG sinxronizatsiya holatidan xabardor emas va uzoq vaqt ishlamay qolishiga yoki ma'lumotlar yo'qolishiga olib kelishi mumkin.

6.3 Monitoring va texnik xizmat ko'rsatish

Mavjudlik guruhi boshqaruv panelidan foydalanib, sinxronizatsiya holatini kuzatib boring, navbatni yuboring va navbatni muntazam ravishda qayta bajaring SQL Server Management Studio yoki Dynamic Management Views (DMV) . Ikkilamchi qurilmada qayta bajarish navbatining ortib borishi, ishdan chiqishni tiklashni kechiktiradigan I/U to'siqni ko'rsatadi.
Birlamchi nusxalardan yaxlitlik tekshiruvlarini o'chirish uchun ikkilamchi replikalarda DBCC CHECKDB ni ishga tushiring. Bizning ma'lumotlarimizga qarang. DBCC CHECKDB qo'llanmasi Batafsil ma'lumot olish uchun.
Qo'llash SQL Server Rolling yangilanishlari yordamida yamalar: avval ikkilamchi nusxalarni yamoqlang, yamalgan ikkilamchiga rejalashtirilgan qo'lda ishlamay qolishni amalga oshiring, so'ngra avvalgi asosiyni yamoqlang. Bu ishlamay qolish vaqtini bitta ishlamay qolish davomiyligi bilan cheklaydi.
Ishlab chiqarish bo'lmagan muhitda muntazam ravishda ishdan chiqishni sinab ko'ring. Hech qachon sinovdan o'tkazilmagan avtomatik ishdan chiqish ishonchli tiklash strategiyasi emas.
Mavjudlik guruhining sog'liq holatidagi o'zgarishlar, replika rollarining o'zgarishi va sinxronizatsiya xatolari haqida ogohlantirishlarni quyidagi amallardan foydalanib sozlang: SQL Server Agent yoki maxsus monitoring vositasi, masalan SQL Server Ishlash monitori.

7. Tss

Savol: Bu nima? SQL Server Doim yoniqmi?

A: SQL Server Always On — Microsoft’ning yuqori darajadagi mavjudlik va falokatdan keyin tiklanish platformasi 2017-yilda taqdim etilgan. SQL Server 2012. U ikkita texnologiyani o'z ichiga oladi - Always On Availability Groups va Always On Failover Cluster Instances - bu apparat, dasturiy ta'minot yoki sayt nosozliklari yuzaga kelganda avtomatlashtirilgan ishdan chiqish, ma'lumotlar zaxirasini va ma'lumotlar bazalariga uzluksiz kirishni ta'minlaydi.

Savol: Doim yoqilgan mavjudlik guruhlari va ishlamay qolish klasteri misollari o'rtasidagi farq nima?

A: Mavjudlik guruhlari ma'lumotlar bazasi darajasida ishlaydi, ma'lumotlarni jurnallarni jo'natish orqali mustaqil ikkilamchi replikalarga ko'paytiradi va umumiy saqlashni talab qilmaydi. Ishdan chiqish klasteri misollari misol darajasida ishlaydi, barcha tugunlar tomonidan kirish mumkin bo'lgan umumiy saqlashni talab qiladi va barcha ma'lumotlar bazalarida birlik sifatida ishlamay qoladi. AG o'qiladigan ikkilamchi va o'rnatilgan DR ni qo'llab-quvvatlaydi; FCI bunday qilmaydi.

Savol: Doim yoqilgan mavjudlik guruhlari uchun umumiy xotira kerakmi?

A: Yo'q. Har bir AG replikasi ma'lumotlar bazalarining o'z mustaqil nusxasini mahalliy xotirada saqlaydi. Umumiy xotira faqat Failover Cluster Instances dan foydalansangiz talab qilinadi.ost AG nusxalari.

Savol: Men "Doim yoqilgan" funksiyasidan foydalana olamanmi? SQL Server Standart nashrmi?

A: SQL Server Standard Edition asosiy mavjudlik guruhlarini qo'llab-quvvatlayditarbilan tinglash SQL Server 2016-yilda chiqarilgan, ammo sezilarli cheklovlar bilan: har bir AG uchun bitta ma'lumotlar bazasi, maksimal ikkita nusxa va o'qiladigan ikkilamchi qo'llab-quvvatlash yo'q. FCI ushbu cheklovlarsiz Standard Editionda mavjud. To'liq Always On funksiyasi uchun Enterprise Edition talab qilinadi.

Savol: Mavjudlik guruhidagi maksimal nusxalar soni qancha?

A: SQL Server Enterprise Edition to'qqiztagacha replikani qo'llab-quvvatlaydi: bitta asosiy va sakkizta ikkilamchi. Tarqatilgan mavjudlik guruhlari buni ikkita alohida mavjudlik guruhlari bo'yicha 18 ta replikaga kengaytirishi mumkin.

Savol: FCI-h mumkinmi?osted replikalari avtomatik AG ishdan chiqishini ishlatadimi?

A: Yo'q. Mavjudlik nusxasi h bo'lgandaostFailover Cluster Instance’da yaratilgan bo‘lsa, ushbu replika uchun avtomatik mavjudlik guruhining ishdan chiqishi qo‘llab-quvvatlanmaydi. FCI-h bilan bog‘liq barcha AG ishdan chiqishiosttahrirlangan nusxalar qo'lda aralashuvni talab qiladi.

Savol: Sinxron va asinxron kompilyatsiya rejimlari o'rtasidagi farq nima?

A: Sinxron-kommit rejimi birlamchi tizimdan ikkilamchi tizimning kompilyatsiya qilishdan oldin jurnal yozuvlarini qattiqlashtirishini kutishni talab qiladi, bu esa c da nol ma'lumotlar yo'qotilishini (RPO = 0) ta'minlaydi.ost qo'shilgan yozish kechikishi. Asinxron-kommit rejimi birlamchi tizimga kutmasdan kommit qilish imkonini beradi, bu esa kechikishni kamaytiradi, lekin ikkilamchi tizim barcha jurnal yozuvlarini qabul qilmasdan oldin birlamchi tizim ishlamay qolsa, ma'lumotlar yo'qotilishi xavfini tug'diradi. Mahalliy HA replikalari uchun sinxron va uzoqdagi DR replikalari uchun asinxrondan foydalaning.

Savol: A qancha vaqt davom etadi SQL Server Doim ishdan chiqishni qabul qilishdami?

A: Sinxron AG replikasi uchun avtomatik ishdan chiqish odatda normal sharoitlarda 30 soniyadan kamroq vaqt ichida yakunlanadi. FCI ishdan chiqishi odatda ma'lumotlar bazasini tiklash vaqtiga qarab 20-60 soniya davom etadi. Haqiqiy davomiylik ish yukiga, ma'lumotlar bazasi hajmiga va WSFC da sozlangan sog'liqni tekshirish vaqti tugashi sozlamalariga bog'liq.

Savol: Ishdan chiqish vaqtida mijoz ulanishlari bilan nima sodir bo'ladi?

A: Mavjud ulanishlar ishlamay qolganda uziladi. Mavjudlik guruhi tinglovchisidan foydalanadigan va ulanishni qayta urinish mantig'ini o'z ichiga olgan ilovalar ishlamay qolgandan so'ng avtomatik ravishda yangi asosiy tarmoqqa qayta ulanadi. MultiSubnetFailover=Ulanish satrlariga to'g'ri qo'shish ko'p tarmoqli joylashtirishlarda qayta ulanish tezligini oshiradi.

Savol: Qanday murojaat qilaman SQL Server Doim yoqilgan muhitda minimal ishlamay qoladigan yamalarmi?

A: Rolling yangilanishlaridan foydalaning: avval ikkilamchi replikalarni yamoqlang, so'ngra yamoqlangan ikkilamchiga rejalashtirilgan qo'lda ishdan bo'shatishni amalga oshiring va nihoyat avvalgi asosiyni yamoqlang. Bu ishlamay qolish vaqtini bitta rejalashtirilgan ishdan bo'shatish davomiyligi bilan cheklaydi - odatda bir daqiqadan kamroq.

Savol: Doim yoqilgan mavjudlik guruhlarini Failover Cluster misollari bilan birlashtira olamanmi?

A: Ha. Siz buni qila olasizost AG replikalari FCI nusxalarida ham misol darajasida, ham ma'lumotlar bazasi darajasida ishlamay qolishdan himoyalanishga erishish uchun ishlatiladi. Har bir FCI bitta AG replikasi sifatida hisoblanadi. Ushbu topologiya bitta tugunning ishlamasligini ta'minlash uchun WSFC tugunlarini puxta rejalashtirishni talab qiladi.ostFCI ishdan chiqishi mumkin bo'lgan har qanday vaziyatdan so'ng, bir xil AGning ikkita nusxasi.

Savol: Agar ma'lumotlar bazam doimo yoqilgan muhitda buzilgan bo'lsa, nima qilishim kerak?

A: Avvalo, buzilish barcha replikalarda yoki faqat birlamchi nusxalarda mavjudligini tekshiring. Agar sog'lom ikkilamchi nusxa mavjud bo'lsa, darhol unga murojaat qiling. Barcha replikalardagi buzilishlar uchun toza zaxira nusxasidan tiklang. Buzilishlarni erta aniqlash uchun ikkilamchi replikalarda muntazam ravishda DBCC CHECKDB ni ishga tushiring. Agar zaxira nusxalari ham ta'sirlangan bo'lsa, ixtisoslashgan SQL Server ma'lumotlarni tiklash vositasi oxirgi chora sifatida shikastlangan MDF fayllaridan ma'lumotlarni olishga urinishi mumkin.

Savol: Doim mavjud bo'lgan guruhlar eski guruhlar bilan qanday taqqoslanadi SQL Server HA yechimlari?

A: AG kabi eski texnologiyalarni almashtiradi log yetkazib berish va replikatsiyaJurnallarni jo'natish qo'lda almashtirishni talab qiladi va avtomatik rol o'tishini talab qilmaydi; replikatsiya HA o'rniga ma'lumotlarni tarqatish uchun mo'ljallangan. AG avtomatlashtirilgan almashtirishni, sinxronlashtirilgan commit bilan nol ma'lumotlar yo'qotilishini va o'qilishi mumkin bo'lgan ikkilamchi fayllarni taqdim etadi - bu texnologiyalar mos kela olmaydigan imkoniyatlar.

8. Xulosa

SQL Server Always On yuqori darajadagi mavjudlik va falokatlardan keyin tiklanish uchun moslashuvchan, korporativ darajadagi platformani taqdim etadi. Always On Availability Groups - bu m uchun to'g'ri tanlov.ost zamonaviy joylashtirishlar: u umumiy saqlashga bo'lgan ehtiyojni bartaraf etadi, o'qiladigan ikkilamchi fayllarni qo'llab-quvvatlaydi va mahalliy HA va saytlararo DR ni bitta konfiguratsiyada qayta ishlaydi. Failover klaster nusxalari misol darajasidagi ishdan chiqish va mavjud umumiy saqlash infratuzilmasi asosiy talablar bo'lganda mustahkam variant bo'lib qoladi. Ikkala texnologiyani birlashtirish mavjud bo'lgan eng chuqur himoyani ta'minlaydi - c daost infratuzilmaga investitsiyalarning ko'payishi va operatsion murakkablik.

Qaysi yechimni tanlashingizdan qat'i nazar, asosiy qoidalar bir xil: avval RTO va RPO talablaringizni aniqlang, topologiyangizni shular atrofida loyihalang. taroladi va muntazam ravishda ishdan chiqishni sinab ko'radi. Yaxshi joriy etilgan va puxta sinovdan o'tgan Always On yechimi ishlab chiqarishdagi nosozliklar yuzaga kelganda oldindan aytib bo'ladigan tarzda tiklanadi.

Muallif haqida

Yuan Sheng 10 yildan ortiq tajribaga ega bo'lgan katta ma'lumotlar bazasi administratori (DBA). SQL Server muhitlar va korporativ ma'lumotlar bazasini boshqarish. U moliyaviy xizmatlar, sog'liqni saqlash va ishlab chiqarish tashkilotlarida ma'lumotlar bazasini tiklashning yuzlab stsenariylarini muvaffaqiyatli hal qildi.

Yuan ixtisoslashgan SQL Server ma'lumotlar bazasini tiklash, yuqori mavjudlik echimlari va ishlashni optimallashtirish. Uning keng ko‘lamli amaliy tajribasiga ko‘p terabaytli ma’lumotlar bazalarini boshqarish, “Always On Availability Groups”ni amalga oshirish va muhim biznes tizimlari uchun avtomatlashtirilgan zaxira va tiklash strategiyalarini ishlab chiqish kiradi.

Yuan o'zining texnik tajribasi va amaliy yondashuvi orqali ma'lumotlar bazasi ma'murlari va IT mutaxassislariga murakkab muammolarni hal qilishga yordam beradigan keng qamrovli qo'llanmalarni yaratishga e'tibor qaratadi. SQL Server muammolarni samarali hal qiladi. U eng so'nggi yangiliklardan xabardor bo'lib qoladi SQL Server relizlar va Microsoft-ning rivojlanayotgan ma'lumotlar bazasi texnologiyalari, uning tavsiyalari haqiqiy dunyodagi eng yaxshi amaliyotlarni aks ettirishini ta'minlash uchun tiklash stsenariylarini muntazam ravishda sinab ko'radi.

haqida savollaringiz bor SQL Server tiklash yoki ma'lumotlar bazasi muammolarini bartaraf etish bo'yicha qo'shimcha yo'riqnoma kerakmi? Yuan tabriklaydi mulohazalar va takliflar ushbu texnik resurslarni yaxshilash uchun.