გააზიარე ახლა:
სარჩევი დამალვა
2. ყოველთვის ხელმისაწვდომი ჯგუფების არქიტექტურა
4. ყოველთვის ჩართული ხელმისაწვდომობის ჯგუფების კონფიგურაცია

1. ყოველთვის ჩართული ხელმისაწვდომობის ჯგუფების გაგება

1.1 რა არის ეს და როგორ მუშაობს

ყოველთვის ხელმისაწვდომი ჯგუფები (AG) არის SQL Server Enterprise მაღალი ხელმისაწვდომობა და კატასტროფის შემდეგ აღდგენის გადაწყვეტა, რომელიც მუშაობს მონაცემთა ბაზის დონეზე. ხელმისაწვდომობის ჯგუფი აერთიანებს ერთ ან მეტ მომხმარებლის მონაცემთა ბაზას ერთ გადართვის ერთეულში და ახდენს მათ რეპლიკაციას რვა მეორად რეპლიკამდე ტრანზაქციების ჟურნალის უწყვეტი მიწოდების გზით. როდესაც პირველადი რეპლიკა ვერ ხერხდება, დანიშნული სინქრონული მეორადი მონაცემთა ბაზა ავტომატურად იღებს მას, აღადგენს წვდომას წამებში, საერთო მეხსიერების ან ხელით ჩარევის გარეშე.

1.2 ყოველთვის ჩართული ხელმისაწვდომობის ჯგუფები და გადამისამართების კლასტერული ინსტანციები

SQL Server Always On მოიცავს ორ განსხვავებულ ტექნოლოგიას: ხელმისაწვდომობის ჯგუფებს (AG) და Failover Cluster Instances (FCI):

ყოველთვის ხელმისაწვდომი ჯგუფები ყოველთვის ჩართულია Failover კლასტერის ეგზემპლარები
გადამისამართების დიაპაზონი მონაცემთა ბაზის დონე ეგზემპლარის დონე (ყველა მონაცემთა ბაზა ერთდროულად ვერ ხერხდება)
მონაცემთა რეპლიკაცია ლოგ-ზე დაფუძნებული რეპლიკაცია თითოეულ მეორადისთვის არცერთი — ყველა კვანძი ერთსა და იმავე მეხსიერებას იზიარებს
საერთო საცავი არ არის საჭირო საჭიროა (Storage Area Network (SAN), iSCSI, S2D ან SMB)
წაკითხვადი მეორადი ჩანაწერები დიახ არა
კატასტროფის აღდგენა ჩაშენებული (საიტებს შორის ასინქრონული რეპლიკები) არ არის ჩაშენებული AG-სთან დაწყვილების გარეშე

როდის გამოვიყენოთ თითოეული: გამოიყენეთ FCI, როდესაც გჭირდებათ ეგზემპლარის დონის გადართვა და უკვე გაქვთ საერთო შენახვის ინფრასტრუქტურა. გამოიყენეთ AG, როდესაც გჭირდებათ მონაცემთა ბაზის დონის დეტალიზაცია, წაკითხვადი მეორადი ფაილები ან კატასტროფის შემდეგ აღდგენა. ყველაზე სრულყოფილი დაცვისთვის, გააერთიანეთ ორივე: გაუშვით თითოეული რეპლიკა FCI კვანძად და დააკავშირეთ ისინი AG-ში.

1.3 უპირატესობები და შეზღუდვები

უპირატესობები:

  • ავტომატური გადართვა თითქმის ნულოვანი აღდგენის დროის დანიშნულებით (RTO) სინქრონული რეპლიკებისთვის;
  • ნულოვანი მონაცემთა დაკარგვა (აღდგენის წერტილის მიზანი (RPO) = 0) სინქრონული დადასტურების რეჟიმში;
  • საერთო საცავი არ არის საჭირო — თითოეული რეპლიკა იყენებს დამოუკიდებელ ლოკალურ საცავს;
  • წაკითხვადი მეორადი მოწყობილობები ანგარიშგებისა და სარეზერვო სამუშაო დატვირთვების განტვირთვას ახდენს პირველადიდან;
  • ერთ კონფიგურაციაში მხარს უჭერს როგორც ლოკალურ მაღალი ხელმისაწვდომობის (HA), ასევე საიტებს შორის კატასტროფის აღდგენის (DR) ფუნქციებს.

შეზღუდვები:

  • ყველა რეპლიკაზე საჭიროა Windows Server-ის Failover კლასტერიზაცია;
  • Enterprise Edition სრული ფუნქციებისთვის (სტანდარტული გამოცემა მხარს უჭერს Basic AG-ს მნიშვნელოვანი შეზღუდვებით);
  • სინქრონული ჩაწერის რეჟიმი ჩაწერის ოპერაციებს ქსელის ორმხრივი დატვირთვის დროის პროპორციულად ზრდის შეყოვნებას;
  • შესვლები, SQL Agent-ის დავალებები და დაკავშირებული სერვერები ავტომატურად არ სინქრონიზდება SQL Server 2019 და უფრო ადრე (გადაწყვეტილია SQL Server 2022 წელს ხელმისაწვდომობის ჯგუფები შეიცავდა).

2. ყოველთვის ხელმისაწვდომი ჯგუფების არქიტექტურა

2.1 ძირითადი კომპონენტები და კონცეფციები

2.1.1 ხელმისაწვდომობის მონაცემთა ბაზები

ხელმისაწვდომობის მონაცემთა ბაზები არის მომხმარებლის მონაცემთა ბაზები, რომლებიც მონაწილეობენ ხელმისაწვდომობის ჯგუფში. ეს მონაცემთა ბაზები უნდა აკმაყოფილებდეს კონკრეტულ მოთხოვნებს: მათ უნდა გამოიყენონ სრული აღდგენის მოდელი, ჰქონდეთ სრული სარეზერვო ასლი და ხელმისაწვდომობის ჯგუფში დამატებამდე არსებობდნენ პირველად რეპლიკაზე.

როდესაც მონაცემთა ბაზა უერთდება ხელმისაწვდომობის ჯგუფს, ის ხდება სინქრონიზებული ნაკრების ნაწილი, რომელიც ერთიანად ვერ ხერხდება. ხელმისაწვდომობის ჯგუფში შემავალი ყველა მონაცემთა ბაზა იზიარებს ერთსა და იმავე ვერ ხერხდება, რაც იმას ნიშნავს, რომ თუ პირველადი რეპლიკა ვერ ხერხდება, ყველა მონაცემთა ბაზა ერთდროულად გადადის ერთსა და იმავე მეორად რეპლიკაზე. ეს უზრუნველყოფს თანმიმდევრულობას იმ აპლიკაციებისთვის, რომლებიც ეყრდნობიან მრავალ დაკავშირებულ მონაცემთა ბაზას.

2.1.2 ხელმისაწვდომობის რეპლიკები

ხელმისაწვდომობის რეპლიკებია SQL Server ინსტანციები, რომლებიც მასპინძლობენ ხელმისაწვდომობის მონაცემთა ბაზების ასლებს. თითოეული რეპლიკა ინახავს მონაცემთა ბაზების საკუთარ ფიზიკურ ასლს, რომელიც სინქრონიზებულია ტრანზაქციების ჟურნალის ჩანაწერების გადაგზავნის გზით. ხელმისაწვდომობის ჯგუფს შეუძლია შეიცავდეს ცხრა რეპლიკას: ერთ პირველად რეპლიკას და რვა მეორად რეპლიკას.

2.1.3 პირველადი რეპლიკა

პირველადი რეპლიკა მასპინძლობს ხელმისაწვდომობის მონაცემთა ბაზების წაკითხვა-ჩაწერის ასლს. მონაცემთა ყველა ცვლილება (INSERT, UPDATE, DELETE) ხორციელდება პირველად რეპლიკაზე. კლიენტის აპლიკაციები უკავშირდება პირველად რეპლიკას ყველა ჩაწერის ოპერაციისთვის და, ნაგულისხმევად, წაკითხვის ოპერაციებისთვისაც.

2.1.4 მეორადი რეპლიკები

მეორადი რეპლიკები მასპინძლობენ ხელმისაწვდომობის მონაცემთა ბაზების მხოლოდ წაკითხვის ასლებს, რომლებიც შენარჩუნებულია პირველადი რეპლიკიდან მიღებული ტრანზაქციების ჟურნალის ჩანაწერების უწყვეტი გამოყენების გზით. თითოეული მეორადი რეპლიკა იღებს, ამაგრებს და იყენებს ჟურნალის ჩანაწერებს, რათა მისი მონაცემთა ბაზის ასლები სინქრონიზებული იყოს პირველადთან.

ძირითადი კომპონენტებისა და კონცეფციების ინფოგრაფიკა SQL Server ყოველთვის ხელმისაწვდომობის ჯგუფებში

2.2 ხელმისაწვდომობის რეჟიმები

2.2.1 სინქრონული დადასტურების რეჟიმი

სინქრონული დადასტურების რეჟიმი უზრუნველყოფს მონაცემთა ნულოვანი დაკარგვისგან დაცვას, რადგან პირველადი რეპლიკა მოითხოვს, რომ დაელოდოს დადასტურებას, რომ ტრანზაქციების ჟურნალის ჩანაწერები გამყარებულია მეორად რეპლიკაზე ტრანზაქციების დადასტურებამდე. ეს რეჟიმი აუცილებელია მაღალი ხელმისაწვდომობის კონფიგურაციებისთვის, სადაც მონაცემთა დაკარგვა მიუღებელია.

2.2.2 ასინქრონული დადასტურების რეჟიმი

ასინქრონული ჩაბარების რეჟიმი პრიორიტეტს ანიჭებს პირველადი რეპლიკის მუშაობას, რაც ტრანზაქციებს საშუალებას აძლევს ჩააბარონ მეორეული რეპლიკების მიერ ლოგის გამკაცრების დადასტურების მოლოდინის გარეშე. ეს რეჟიმი შესაფერისია კატასტროფის აღდგენის რეპლიკებისთვის ან როდესაც ქსელის შეყოვნება სინქრონულ ჩაბარებას არაპრაქტიკულს ხდის.

კომპრომისი არის მონაცემთა პოტენციური დაკარგვა ჩავარდნის დროს. თუ პირველადი რეპლიკა ვერ მოხერხდა, შესაძლოა ზოგიერთი ჩადენილი ტრანზაქცია ვერ მოხვედრილიყო მეორად რეპლიკამდე. მონაცემთა პოტენციური დაკარგვის რაოდენობა დამოკიდებულია ქსელის გამტარობაზე, მეორადი რეპლიკის მუშაობაზე და შეცდომის დროზე. ორგანიზაციებმა უნდა მიიღონ ეს რისკი ასინქრონული რეჟიმის გამოყენებისას.

ინფოგრაფიკა SQL Server ყოველთვის ხელმისაწვდომობის რეჟიმებში, მათ შორის სინქრონული და ასინქრონული დადასტურების რეჟიმში.

2.3 გადართვის ტიპები

2.3.1 ავტომატური გადართვა

ავტომატური გადართვა (failover) ხელმისაწვდომობის ჯგუფს საშუალებას აძლევს, აღმოაჩინოს პირველადი რეპლიკის გაუმართაობა და ავტომატურად გადაიყვანოს მეორადი რეპლიკა პირველად რეპლიკაში ადმინისტრატორის ჩარევის გარეშე. ეს შესაძლებლობა მინიმუმამდე ამცირებს RTO-ს, რადგან აღმოფხვრის წარუმატებლობებზე ხელით რეაგირების საჭიროებას.

ავტომატური გადართვა მოითხოვს სინქრონული დადასტურების რეჟიმს მონაცემთა ნულოვანი დაკარგვის უზრუნველსაყოფად. ჩართვის შემთხვევაში, ხელმისაწვდომობის ჯგუფი განუწყვეტლივ აკონტროლებს პირველადი რეპლიკის მდგომარეობას. თუ პირველადი არ რეაგირებს ან ვერ ხერხდება, Windows Server-ის გადართვის კლასტერი იწყებს ავტომატურ გადართვას დანიშნულ მეორად რეპლიკაზე.

2.3.2 ხელით გადართვა

ხელით გადართვა ადმინისტრატორებს საშუალებას აძლევს განზრახ გადართონ ძირითადი რეპლიკის როლი მეორად რეპლიკაზე, როგორც წესი, დაგეგმილი ტექნიკური მომსახურების ან ტესტირების მიზნებისთვის. ავტომატური გადართვისგან განსხვავებით, ხელით გადართვის დასაწყებად საჭიროა ადმინისტრატორის აშკარა მოქმედება.

სინქრონული დადასტურების რეპლიკებისთვის ხელმისაწვდომია ხელით გადართვა მონაცემთა დაკარგვის გარეშე. ადმინისტრატორი იწყებს გადართვას შემდეგი გზით: SQL Server Management Studio, Transact-SQL ან PowerShell. პირველადი რეპლიკა ასრულებს მიმდინარე ტრანზაქციების დამუშავებას, აგზავნის ყველა დარჩენილ ჟურნალის ჩანაწერს სამიზნე მეორად რგოლში და ელოდება დადასტურებას პირველადი როლის გადაცემამდე.

ხელით გადართვა ასევე შეიძლება მოხდეს ასინქრონული დადასტურების რეპლიკების შემთხვევაში, მაგრამ ეს მოითხოვს იძულებით გადართვას მონაცემთა დაკარგვის პოტენციალით. ადმინისტრატორებმა იძულებითი ხელით გადართვა უნდა გამოიყენონ მხოლოდ რეალური კატასტროფების დროს, როდესაც პირველადი რეპლიკა მიუწვდომელია და მონაცემთა დაკარგვა მისაღებია გახანგრძლივებულ შეფერხებასთან შედარებით.

2.3.3 იძულებითი გადართვა

იძულებითი გადართვა საშუალებას იძლევა გადაერთოს ასინქრონულ მეორად რეპლიკაზე ან სრულად არსინქრონიზებულ მეორად რეპლიკაზე, პოტენციური დაკარგვის აშკარა აღიარებით. ეს ვარიანტი გამოიყენება როგორც უკიდურესი საშუალება, როდესაც პირველადი რეპლიკა მიუწვდომელია და სინქრონიზებული მეორადი რეპლიკა არ არსებობს.

ინფოგრაფიკა SQL Server ყოველთვის გადართვის ტიპებზე, მათ შორის ავტომატურ, მექანიკურ და იძულებით გადართვაზე.

2.4 მონაცემთა სინქრონიზაცია

2.4.1 როგორ მუშაობს მონაცემთა სინქრონიზაცია

მონაცემთა სინქრონიზაცია Always On Availability Groups-ში ხორციელდება ტრანზაქციების ჟურნალის ჩანაწერების უწყვეტი გადაცემით პირველადი რეპლიკიდან ყველა მეორად რეპლიკაში. ჟურნალებზე დაფუძნებული ეს სინქრონიზაცია უზრუნველყოფს თანმიმდევრულობას და ამავდროულად საშუალებას იძლევა თითოეული რეპლიკისთვის დამოუკიდებელი შენახვისა.

2.4.2 ტრანზაქციების ჟურნალის ჩანაწერები და მათი გამკაცრება

ტრანზაქციების ჟურნალის გამყარება კრიტიკული ეტაპია, რომლის დროსაც ჟურნალის ჩანაწერები იწერება მეორად რეპლიკებზე მდგრად საცავში. გამყარება უზრუნველყოფს, რომ ჟურნალის ჩანაწერები გადაურჩეს მეორადი რეპლიკების ჩავარდნებს და აღდგენის დროს მათი ხელახლა დაკვრა შესაძლებელი იქნება.

ინფოგრაფიკა SQL Server მუდმივად ჩართულია მონაცემთა სინქრონიზაციის პროცესი.

2.5 წაკითხვის მასშტაბი და წაკითხვადი მეორადი რეპლიკები

2.5.1 მხოლოდ წასაკითხი სამუშაო დატვირთვების განტვირთვა

წაკითხვადი მეორადი რეპლიკები ორგანიზაციებს საშუალებას აძლევს, პირველადი რეპლიკიდან გადატვირთონ წაკითხვის ინტენსიური სამუშაო დატვირთვები, რაც აუმჯობესებს სისტემის საერთო მუშაობას და რესურსების გამოყენებას. წაკითხვის მასშტაბის ეს შესაძლებლობა ხელმისაწვდომობის ჯგუფების ერთ-ერთი მთავარი უპირატესობაა მაღალი ხელმისაწვდომობის ძველ გადაწყვეტილებებთან შედარებით.

ორგანიზაციებმა ხელმისაწვდომობის ჯგუფის კონფიგურაციების შექმნისას უნდა გაითვალისწინონ მხოლოდ წაკითხვის დატვირთვის მოთხოვნები. რამდენიმე წასაკითხ მეორადი სერვერი ანგარიშგების დატვირთვას რამდენიმე სერვერზე გადაანაწილებს. მხოლოდ წაკითხვის მარშრუტიზაციის სიები განსაზღვრავს თანმიმდევრობას, რომლითაც მეორადი სერვერები იღებენ წაკითხვის განზრახვის კავშირებს, რაც დატვირთვის დაბალანსების სტრატეგიებს უზრუნველყოფს.

2.5.2 სარეზერვო ოპერაციები მეორად რეპლიკაებზე

მეორად რეპლიკებზე სარეზერვო ასლების შექმნა ამცირებს პირველად რეპლიკაზე შეყვანის/გამოყვანის (I/O) და ცენტრალური დამუშავების ბლოკის (CPU) დატვირთვას, რაც საშუალებას აძლევს მას ფოკუსირება მოახდინოს ტრანზაქციულ სამუშაო დატვირთვაზე. ეს შესაძლებლობა ეხმარება ორგანიზაციებს დააკმაყოფილონ სარეზერვო ასლების მოთხოვნები წარმოების მუშაობაზე გავლენის გარეშე.

SQL Server მხარს უჭერს მონაცემთა ბაზის სრულ სარეზერვო ასლებს, დიფერენციალურ სარეზერვო ასლებს და ტრანზაქციების ჟურნალის სარეზერვო ასლებს მეორად რეპლიკებზე. სარეზერვო ასლის პარამეტრების კონფიგურაცია შესაძლებელია მეორადი რეპლიკების, პირველადი, მხოლოდ მეორადი ან ნებისმიერი რეპლიკის უპირატესობის მინიჭებით. სარეზერვო ასლის სისტემა ავტომატურად ირჩევს შესაბამის რეპლიკას ამ პარამეტრებისა და მიმდინარე ხელმისაწვდომობის საფუძველზე.

დამატებითი ინფორმაციისთვის SQL Server სარეზერვო ასლი, იხილეთ ჩვენი ყოვლისმომცველი სახელმძღვანელო.

წასაკითხი მასშტაბის და წაკითხვადი მეორადი რეპლიკების ინფოგრაფიკა SQL Server ყოველთვის

2.6 ხელმისაწვდომობის ჯგუფის მსმენელები

2.6.1 ვინ არის მსმენელი?

ხელმისაწვდომობის ჯგუფის მსმენელი არის ვირტუალური ქსელის სახელი (VNN) და IP მისამართი, რომელსაც კლიენტის აპლიკაციები იყენებენ ხელმისაწვდომობის ჯგუფის მონაცემთა ბაზებთან დასაკავშირებლად. მსმენელი ავტომატურად გადამისამართებს კავშირებს მიმდინარე პირველად რეპლიკაზე, რაც გამორიცხავს აპლიკაციების მიერ იმის თვალყურის დევნების საჭიროებას, თუ რომელი სერვერია ამჟამად პირველადი.

2.6.2 კლიენტის კავშირის მარშრუტიზაცია

კლიენტის კავშირის მარშრუტიზაცია მსმენელის მეშვეობით მხარს უჭერს როგორც წაკითხვის-წერის, ასევე მხოლოდ წაკითხვის კავშირის ინტენტებს. მსმენელი ამოწმებს კავშირის მოთხოვნას და აპლიკაციის ინტენტის მიხედვით აგზავნის მას შესაბამის რეპლიკაზე.

ინფოგრაფიკა SQL Server ყოველთვის ხელმისაწვდომია ჯგუფის მსმენელები.

3. წინაპირობები და მოთხოვნები

3.1 Windows Server-ის Failover კლასტერიზაცია ხელმისაწვდომობის ჯგუფებისთვის

3.1.1 Windows Server-ის გადამისამართების კლასტერიზაციის საფუძვლები

Windows Server-ის Failover კლასტერიზაცია (WSFC) უზრუნველყოფს Always On Availability Groups-ის საფუძველს კლასტერის წევრობის, ჯანმრთელობის მონიტორინგისა და Failover Orchestra-ის მართვით. Failover კლასტერის ეგზემპლარებისგან განსხვავებით, ხელმისაწვდომობის ჯგუფები WSFC-ს იყენებენ მხოლოდ კლასტერის კოორდინაციისთვის და არა საერთო საცავის მართვისთვის.

თითოეული SQL Server ხელმისაწვდომობის ჯგუფში მონაწილე ეგზემპლარი უნდა იყოს WSFC კლასტერის კვანძი. კლასტერი მართავს კვორუმის ხმის მიცემას, კვანძის ჯანმრთელობის აღმოჩენას და ხელმისაწვდომობის ჯგუფის რესურსების მდგომარეობას. როდესაც პირველადი რეპლიკა ვერ ხერხდება, WSFC კოორდინაციას უწევს გადართვის პროცესს და აახლებს კლასტერის რესურსებს ახალი პირველადი რეპლიკის ასახვის მიზნით.

Windows Server-ის Failover კლასტერიზაციის (WSFC) საფუძვლების ინფოგრაფიკა SQL Server ყოველთვის ხელმისაწვდომი ჯგუფები

3.1.2 კლასტერული კვორუმის კონფიგურაცია

კლასტერული კვორუმი განსაზღვრავს, თუ რომელ კვანძებს შეუძლიათ მუშაობა ქსელთან დაკავშირების პრობლემების დროს, რაც ხელს უშლის გაყოფილი ტვინის სცენარებს, სადაც მრავალი კვანძი დამოუკიდებლად აცხადებს პრეტენზიას პირველადობაზე. კვორუმის კონფიგურაცია განსაზღვრავს, თუ რა წარმოადგენს კლასტერული გადაწყვეტილებების მიღებისას ხმის მიცემის უმრავლესობის პრინციპს.

ხელმისაწვდომობის ჯგუფებისთვის ხელმისაწვდომია რამდენიმე კვორუმის რეჟიმი:

  • კვანძების უმრავლესობა იყენებს მხოლოდ კლასტერის კვანძების ხმებს და კარგად მუშაობს კენტი რაოდენობის კვანძების მქონე კლასტერებისთვის.
  • კვანძებისა და ფაილების გაზიარების უმრავლესობა ამატებს ფაილის გაზიარების მოწმის ხმის მიცემის შესაძლებლობას, რაც შესაფერისია ლუწი რიცხვის მქონე კვანძების კლასტერებისთვის.
  • კვანძისა და დისკის უმრავლესობა იყენებს დისკის მოწმეს, მაგრამ ნაკლებად გავრცელებულია ხელმისაწვდომობის ჯგუფებისთვის, რადგან გაზიარებული მეხსიერება არ არის საჭირო.

კლასტერული კვორუმის კონფიგურაციის ინფოგრაფიკა SQL Server ყოველთვის ხელმისაწვდომი ჯგუფები

3.1.3 მრავალქსელური კლასტერიზაცია

მრავალქვექსელური კლასტერიზაცია საშუალებას აძლევს ხელმისაწვდომობის ჯგუფის რეპლიკებს მოიცვან სხვადასხვა ქსელის ქვექსელები, რაც მხარს უჭერს გეოგრაფიულად განაწილებულ განლაგებას მონაცემთა ცენტრებში. ეს შესაძლებლობა აუცილებელია კატასტროფის შემდეგ აღდგენის კონფიგურაციებისთვის, სადაც რეპლიკები არსებობს ცალკეულ ადგილებში.

მრავალქვექსელის კლასტერიზაციის ინფოგრაფიკა SQL Server ყოველთვის ხელმისაწვდომი ჯგუფები

3.2 SQL Server გამოცემის მოთხოვნები

3.2.1 საწარმო ვერსიის მახასიათებლები

SQL Server Enterprise Edition უზრუნველყოფს ხელმისაწვდომობის ჯგუფების სრულ ფუნქციონალს შეზღუდვების გარეშე. Enterprise Edition მხარს უჭერს რვა მეორად რეპლიკას, წაკითხვად მეორად რეპლიკას, ავტომატურ დათესვას, განაწილებულ ხელმისაწვდომობის ჯგუფებს და ყველა გაფართოებულ ფუნქციას.

3.2.2 სტანდარტული ვერსიის ფუნქციები (ძირითადი ხელმისაწვდომობის ჯგუფები)

SQL Server 2016 წლის სტანდარტული და შემდგომი გამოცემა მხარს უჭერს ძირითადი ხელმისაწვდომობის ჯგუფებს მნიშვნელოვანი შეზღუდვებით. ძირითადი ხელმისაწვდომობის ჯგუფები უზრუნველყოფენ მაღალი ხელმისაწვდომობის ძირითად ფუნქციონალს უფრო დაბალ ფასად, რაც შესაფერისია უფრო მარტივი მოთხოვნების მქონე ორგანიზაციებისთვის.

4. ყოველთვის ჩართული ხელმისაწვდომობის ჯგუფების კონფიგურაცია

4.1 გარემოს მომზადება

ხელმისაწვდომობის ჯგუფის შექმნამდე, გარემო სათანადოდ უნდა იყოს მომზადებული Active Directory ანგარიშებით, სერვერის კონფიგურაციებითა და ქსელური ინფრასტრუქტურით.

4.1.1 დომენის კონტროლერის დაყენება

Active Directory დომენის კონტროლერი უნდა იყოს კონფიგურირებული ხელმისაწვდომობის ჯგუფის კლასტერის მხარდასაჭერად და SQL Server მომსახურების ანგარიშები.

  1. შედით დომენის კონტროლერში დომენის ადმინისტრატორის სერთიფიკატებით.
  2. ღიაა Server Manager და ნავიგაცია ინსტრუმენტები -> Active Directory-ის მომხმარებლები და კომპიუტერები.
  3. შექმენით ორგანიზაციული ერთეული SQL Server ობიექტები, თუ ერთი არ არსებობს.
  4. დარწმუნდით, რომ ყველა კლასტერის კვანძის კომპიუტერული ობიექტები არსებობს Active Directory-ში.
  5. დარწმუნდით, რომ დომენური სახელების სისტემის (DNS) სერვისები სწორად არის კონფიგურირებული და ყველა სერვერის სახელი სწორად არის აღდგენილი.

Active Directory-ის მომხმარებლებისა და კომპიუტერების განყოფილებაში დააყენეთ Active Directory-ის დომენის კონტროლერი.

4.1.2 მომსახურების ანგარიშების შექმნა

შექმენით Active Directory სერვისის სპეციალური ანგარიშები SQL Server სერვისები თითოეულ კვანძზე.

  1. ღიაა Active Directory-ის მომხმარებლები და კომპიუტერები დომენის კონტროლერზე.
  2. დააწკაპუნეთ მაუსის მარჯვენა ღილაკით შესაბამის ორგანიზაციულ ერთეულზე და აირჩიეთ ახალი -> შესახებ.
  3. შეიყვანეთ სერვისის ანგარიშის სახელი (მაგალითად, svc_SQLServer) და დააყენეთ მომხმარებლის შესვლის სახელი.
  4. დაწკაპეთ შემდეგი და შეიყვანეთ ძლიერი პაროლი.
  5. აირჩიეთ მომხმარებელს არ შეუძლია პაროლის შეცვლა მდე პაროლი არასდროს იწურება.
  6. დაწკაპეთ შემდეგი და მაშინ ფერი ანგარიშის შესაქმნელად.
  7. გაიმეორეთ ნებისმიერი დამატებითი სერვისის ანგარიშისთვის, რომელიც გჭირდებათ (SQL Server აგენტი, SSRS და ა.შ.).

შექმენით ახალი Active Directory მომხმარებლის ანგარიში.

4.1.3 ადმინისტრატორის ნებართვების კონფიგურაცია

სერვისის ანგარიშები და კონფიგურაციისთვის გამოყენებული ანგარიშები SQL Server უნდა ჰქონდეს შესაბამისი ნებართვები ყველა კლასტერულ კვანძზე.

  1. შედით თითოეულ კლასტერულ კვანძოვან სერვერზე.
  2. ღიაა კომპიუტერის მართვა დან დასაწყისი მენიუ ან სერვერის მენეჯერი.
  3. Expand ადგილობრივი მომხმარებლები და ჯგუფები და აირჩიეთ ჯგუფები.
  4. მარჯვენა ღილაკის ადმინი და აირჩიეთ განცხადებები.
  5. დაწკაპეთ დამატება და შეიყვანეთ სერვისის ანგარიშის სახელი.
  6. დაწკაპეთ შეამოწმეთ სახელები ანგარიშის დასადასტურებლად, შემდეგ დააჭირეთ ღილაკს OK.
  7. დაწკაპეთ OK ადმინისტრატორის თვისებების დიალოგური ფანჯრის დასახურად.
  8. გაიმეორეთ ყველა კლასტერის კვანძზე.

დააკონფიგურირეთ ადმინისტრატორის ნებართვები ახალი Active Directory მომხმარებლის ანგარიშისთვის.

4.2 WSFC-ის ინსტალაცია და კონფიგურაცია

Always On Availability Groups-ის ჩართვამდე ყველა კვანძზე უნდა იყოს დაინსტალირებული და კონფიგურირებული Windows Server Failover Clustering.

4.2.1 Failover კლასტერიზაციის ფუნქციის ინსტალაცია

დააინსტალირეთ Failover Clustering ფუნქცია თითოეულ სერვერზე, რომელიც მონაწილეობას მიიღებს ხელმისაწვდომობის ჯგუფში.

  1. ღიაა Server Manager პირველ კლასტერულ კვანძზე.
  2. დაწკაპეთ მართვა -> როლებისა და ფუნქციების დამატება.
  3. დაწკაპეთ შემდეგი შესავალი ეკრანების მეშვეობით.
  4. აირჩიეთ როლზე დაფუძნებული ან ფუნქციებზე დაფუძნებული ინსტალაცია და დაწკაპეთ შემდეგი.
  5. აირჩიეთ ლოკალური სერვერი და დააჭირეთ ღილაკს შემდეგი.
  6. გამოტოვეთ როლების ეკრანი და დააწკაპუნეთ შემდეგი.
  7. ფუნქციების ეკრანზე აირჩიეთ Failover კლასტერული.
  8. დაწკაპეთ თვისებების დამატება როდესაც მოგეთხოვებათ მართვის ინსტრუმენტების ჩართვა.
  9. დაწკაპეთ შემდეგი და მაშინ ინსტალაცია.
  10. დაელოდეთ ინსტალაციის დასრულებას და დააჭირეთ ღილაკს დახურვა.
  11. გაიმეორეთ ყველა სერვერზე, რომელიც მონაწილეობას მიიღებს კლასტერში.

Failover კლასტერიზაციის ინსტალაცია SQL Server ყოველთვის

4.2.2 Failover კლასტერის შექმნა

ყველა კვანძზე Failover Clustering ფუნქციის ინსტალაციის შემდეგ, შექმენით კლასტერი ერთი კვანძიდან.

  1. ღიაა Failover კლასტერის მენეჯერი საწყისი Server Manager -> ინსტრუმენტები.
  2. დაწკაპეთ შექმენით კლასტერი მოქმედებების პანელში.
  3. დაწკაპეთ შემდეგი დაწყებამდე გვერდზე.
  4. დაწკაპეთ იხილე და დაამატეთ ყველა სერვერი, რომელიც იქნება კლასტერული კვანძები.
  5. დაწკაპეთ შემდეგი ყველა კვანძის დამატების შემდეგ.
  6. მიადევნე ყველა ტესტის გაშვება (რეკომენდებულია) არჩეული და დააწკაპუნეთ შემდეგი.
  7. გადახედეთ ვალიდაციის ტესტის შედეგებს და გამოასწორეთ ნებისმიერი შეცდომა ან გაფრთხილება.
  8. დაწკაპეთ ფერი წარმატებით დადასტურების დასრულების შემდეგ.
  9. შეიყვანეთ კლასტერის სახელი და IP მისამართი.
  10. მონიშვნის მოხსნა დაამატეთ ყველა შესაფერისი მეხსიერება კლასტერს რადგან საერთო საცავი არ არის საჭირო.
  11. დაწკაპეთ შემდეგი და გადახედეთ დადასტურებას.
  12. დაწკაპეთ ფერი კლასტერის შესაქმნელად.

შექმენით Failover Cluster Failover Cluster Manager-ში.

4.2.3 კლასტერის კონფიგურაციის ვალიდაცია

შეამოწმეთ კლასტერის კონფიგურაცია, რათა დარწმუნდეთ, რომ ყველა კვანძს შეუძლია სწორად კომუნიკაცია და კლასტერი სწორად მუშაობს.

  1. In Failover კლასტერის მენეჯერი, დააწკაპუნეთ მაუსის მარჯვენა ღილაკით კლასტერის სახელზე.
  2. აირჩიეთ კლასტერის ვალიდაცია მენიუდან.
  3. დაწკაპეთ შემდეგი დაწყებამდე გვერდზე.
  4. აირჩიეთ ყველა ტესტის გაშვება (რეკომენდებულია) და დაწკაპეთ შემდეგი.
  5. დაწკაპეთ შემდეგი ვალიდაციის ტესტების დასაწყებად.
  6. ტესტების დასრულების შემდეგ გადახედეთ დადასტურების ანგარიშს.
  7. მოაგვარეთ ანგარიშში გამოვლენილი ნებისმიერი ხარვეზი ან გაფრთხილება.
  8. დაწკაპეთ ფერი ოსტატის დასახურად.

გადაამოწმეთ Failover Cluster-ის დადასტურება Failover Cluster Manager-ში.

4.3 ინსტალაცია SQL Server ხელმისაწვდომობის ჯგუფებისთვის

ინსტალაცია SQL Server თითოეულ კვანძზე, რომელიც მონაწილეობას მიიღებს ხელმისაწვდომობის ჯგუფში დამოუკიდებელი ინსტალაციის ვარიანტის გამოყენებით.

  1. გაუშვით SQL Server ინსტალაციის მედია პირველ კვანძზე.
  2. აირჩიეთ ახალი SQL Server დამოუკიდებელი ინსტალაცია.
  3. შეიყვანეთ პროდუქტის გასაღები ან აირჩიეთ შეფასების ვერსია.
  4. მიიღეთ ლიცენზიის პირობები და დააჭირეთ შემდეგი.
  5. შეასრულეთ წინაპირობის შემოწმება და მოაგვარეთ ნებისმიერი პრობლემა.
  6. ფუნქციების შერჩევის გვერდზე აირჩიეთ მონაცემთა ბაზის ძრავის სერვისები.
  7. ინსტანციის სახელის კონფიგურაცია (ყველა კვანძზე ერთი და იგივე ინსტანციის სახელის გამოყენება).
  8. სერვერის კონფიგურაციის გვერდზე მიუთითეთ სერვისის ანგარიშის სერთიფიკატები.
  9. სერვისის გაშვების ტიპების კონფიგურაცია, როგორც ავტომატური.
  10. მონაცემთა ბაზის ძრავის კონფიგურაციის გვერდზე აირჩიეთ ავტორიზაციის რეჟიმი.
  11. ადმინისტრატორის ანგარიშების დამატება.
  12. მონაცემთა დირექტორიების კონფიგურაცია ყველა კვანძში თანმიმდევრული ბილიკების გამოყენებით.
  13. დაასრულეთ ინსტალაცია და დაადასტურეთ წარმატება.
  14. გაიმეორეთ ინსტალაცია ყველა სხვა კლასტერულ კვანძზე იდენტური პარამეტრებით.

ახალი SQL Server დამოუკიდებელი ინსტალაცია

4.4 ყოველთვის ჩართული ხელმისაწვდომობის ჯგუფების ფუნქციის ჩართვა

ინსტალაციის შემდეგ SQL Server ყველა კვანძზე, თითოეულ ინსტანციაზე ჩართეთ Always On Availability Groups ფუნქცია.

4.4.1 ჩართვა SQL Server კონფიგურაციის მენეჯერი

გამოყენება SQL Server კონფიგურაციის მენეჯერი, რათა ჩართოთ Always On Availability Groups გრაფიკული ინტერფეისის მეშვეობით.

  1. ღიაა SQL Server კონფიგურაციის მენეჯერი პირველ კვანძზე.
  2. Expand SQL Server მომსახურება მარცხენა სარკმელზე.
  3. მარჯვენა ღილაკით SQL Server ეგზემპლარი და შერჩევა განცხადებები.
  4. დააჭირეთ AlwaysOn მაღალი ხელმისაწვდომობა Tab.
  5. შეამოწმეთ AlwaysOn ხელმისაწვდომობის ჯგუფების ჩართვა.
  6. დარწმუნდით, რომ Windows-ის გადატვირთვის კლასტერის სახელი სწორია.
  7. დაწკაპეთ OK ცვლილებების შენახვა.
  8. დაწკაპეთ OK გაფრთხილებაზე, რომ სერვისი უნდა გადაიტვირთოს.
  9. მარჯვენა ღილაკით SQL Server მომსახურება და არჩევა რესტარტი.
  10. დაელოდეთ სერვისის წარმატებით გადატვირთვას.
  11. გაიმეორეთ ყველა კლასტერის კვანძზე.

ჩართვა SQL Server ყოველთვის ხელმისაწვდომი ჯგუფები SQL Server კონფიგურაციის მენეჯერი

4.4.2 ჩართვა PowerShell-ის მეშვეობით

PowerShell გთავაზობთ სკრიპტირებულ მეთოდს, რათა ჩართოთ Always On Availability Groups მრავალ კვანძზე.

  1. გახსენით PowerShell ადმინისტრატორის სახელით პირველ კვანძზე.
  2. იმპორტირება SQL Server PowerShell მოდული:
    Import-Module SQLPS -DisableNameChecking
  3. ყოველთვის ჩართული ხელმისაწვდომობის ჯგუფების ჩართვა:
    Enable-SqlAlwaysOn -ServerInstance "ServerName\InstanceName" -Force
  4. სერვისი ავტომატურად გადაიტვირთება Force პარამეტრის გამოყენებისას.
  5. დარწმუნდით, რომ ფუნქცია ჩართულია:
    Get-ItemProperty "SQLSERVER:\SQL\ServerName\InstanceName" | Select-Object IsHadrEnabled
  6. გაიმეორეთ თითოეული კლასტერის კვანძისთვის, შესაბამისი სერვერისა და ეგზემპლარის სახელების ჩანაცვლებით.

4.4.3 ფუნქციის ჩართვის დადასტურება

კონფიგურაციის გაგრძელებამდე დარწმუნდით, რომ Always On Availability Groups ჩართულია ყველა ინსტანციაში.

  1. დაუკავშირდით თითოეულს SQL Server მაგალითის გამოყენებით SQL Server მენეჯმენტის სტუდია.
  2. გახსენით ახალი შეკითხვის ფანჯარა და შეასრულეთ:
    SELECT SERVERPROPERTY('IsHadrEnabled')
  3. დარწმუნდით, რომ შედეგი არის 1 (ჩართულია).
  4. შეამოწმეთ ეს SQL Server ეგზემპლარი გამოჩნდება Failover Cluster Manager-ში კლასტერის როლების ქვეშ.
  5. გადაამოწმეთ ხელმისაწვდომობის ჯგუფის საბოლოო წერტილის არსებობა შემდეგი შესრულებით:
    SELECT * FROM sys.endpoints WHERE type_desc = 'DATABASE_MIRRORING'
  6. თუ საბოლოო წერტილი არ არსებობს, ის შეიქმნება ხელმისაწვდომობის ჯგუფის შექმნისას.

4.5 მონაცემთა ბაზების მომზადება ხელმისაწვდომობის ჯგუფებისთვის

მონაცემთა ბაზები უნდა აკმაყოფილებდეს კონკრეტულ მოთხოვნებს, სანამ ისინი ხელმისაწვდომობის ჯგუფში დაემატება.

4.5.1 მონაცემთა ბაზის აღდგენის მოდელის მოთხოვნები

ხელმისაწვდომობის ჯგუფში დამატებამდე, პირველად რეპლიკაზე მონაცემთა ბაზის აღდგენის მოდელი FULL-ზე შეცვალეთ.

  1. დაკავშირება პირველად რეპლიკასთან გამოყენებით SQL Server მენეჯმენტის სტუდია.
  2. დააწკაპუნეთ მაუსის მარჯვენა ღილაკით მონაცემთა ბაზაზე და აირჩიეთ განცხადებები.
  3. აირჩიეთ პარამეტრები გვერდზე.
  4. შეცვლა აღდგენის მოდელი to სრული.
  5. დაწკაპეთ OK ცვლილების შესანახად.
  6. ალტერნატიულად, გამოიყენეთ Transact-SQL:
    ALTER DATABASE DatabaseName SET RECOVERY FULL;

მონაცემთა ბაზის აღდგენის მოდელის შეცვლა სრულზე

4.5.2 მონაცემთა ბაზის სრული სარეზერვო ასლის შექმნა

ხელმისაწვდომობის ჯგუფებისთვის საჭირო სარეზერვო ასლის ჯაჭვის დასადგენად, შექმენით მონაცემთა ბაზის სრული სარეზერვო ასლი.

  1. In SQL Server Management Studio-ში, დააწკაპუნეთ მაუსის მარჯვენა ღილაკით მონაცემთა ბაზაზე.
  2. აირჩიეთ ამოცანები -> უკან მდე.
  3. შემოწმება სარეზერვო ტიპი არის მითითებული სრული.
  4. აირჩიეთ სარეზერვო ასლის შექმნის ადგილი ან დაამატეთ ახალი.
  5. დაწკაპეთ OK სარეზერვო ასლის შესასრულებლად.
  6. ალტერნატიულად, გამოიყენეთ Transact-SQL:
    BACKUP DATABASE DatabaseName TO DISK = 'C:\Backup\DatabaseName.bak';

შექმენით სრული სარეზერვო ასლი SQL Server მონაცემთა ბაზა SQL Server მენეჯმენტის სტუდია.

4.5.3 ტრანზაქციების ჟურნალის სარეზერვო ასლების შექმნა

შექმენით ტრანზაქციების ჟურნალის სარეზერვო ასლი, რათა დარწმუნდეთ, რომ ჟურნალების ჯაჭვი დადგენილია და ინიციალიზაციის დრო მინიმუმამდეა დაყვანილი.

  1. In SQL Server Management Studio-ში, დააწკაპუნეთ მაუსის მარჯვენა ღილაკით მონაცემთა ბაზაზე.
  2. აირჩიეთ ამოცანები -> უკან მდე.
  3. შეცვლა სარეზერვო ტიპი to ტრანზაქციების ჟურნალი.
  4. აირჩიეთ სარეზერვო ასლის შექმნის დანიშნულების ადგილი.
  5. დაწკაპეთ OK სარეზერვო ასლის შესასრულებლად.
  6. ალტერნატიულად, გამოიყენეთ Transact-SQL:
    BACKUP LOG DatabaseName TO DISK = 'C:\Backup\DatabaseName.trn';

შექმენით ტრანზაქციების ჟურნალის სარეზერვო ასლი SQL Server მონაცემთა ბაზა SQL Server მენეჯმენტის სტუდია.

4.6 ხელმისაწვდომობის ჯგუფის შექმნა

შექმენით ხელმისაწვდომობის ჯგუფი რამდენიმე ხელმისაწვდომი მეთოდიდან ერთ-ერთის გამოყენებით, თქვენი პრეფერენციებისა და ავტომატიზაციის მოთხოვნების შესაბამისად.

4.6.1 ახალი ხელმისაწვდომობის ჯგუფის ოსტატის გამოყენება

ახალი ხელმისაწვდომობის ჯგუფის ოსტატი უზრუნველყოფს გრაფიკულ ინტერფეისს ხელმისაწვდომობის ჯგუფების შესაქმნელად.

  1. In SQL Server Management Studio-ში დაუკავშირდით ინსტანციას, რომელიც ძირითად რეპლიკას განათავსებს.
  2. Expand AlwaysOn მაღალი ხელმისაწვდომობა ობიექტის მკვლევარში.
  3. მარჯვენა ღილაკის ხელმისაწვდომობის ჯგუფები და აირჩიეთ ახალი ხელმისაწვდომობის ჯგუფის ოსტატი.
    ახლის შესაქმნელად, დაიწყეთ ხელმისაწვდომობის ახალი ჯგუფის ოსტატი. SQL Server ყოველთვის ხელმისაწვდომობის ჯგუფი
  4. დაწკაპეთ შემდეგი შესავლის გვერდზე.
  5. შეიყვანეთ ხელმისაწვდომობის ჯგუფის სახელი და დააჭირეთ ღილაკს შემდეგი.
  6. გვერდზე „მონაცემთა ბაზების არჩევა“ აირჩიეთ ჩასართავი მონაცემთა ბაზები.
  7. შეამოწმეთ, რომ მონაცემთა ბაზები აკმაყოფილებს ყველა წინაპირობას და დააჭირეთ ღილაკს შემდეგი.
  8. გვერდზე „რეპლიკების მითითება“, დააწკაპუნეთ რეპლიკის დამატება.
  9. დაკავშირება თითოეულ მეორად რეპლიკა ინსტანციასთან.
  10. თითოეული ეგზემპლარისთვის რეპლიკის თვისებების კონფიგურაცია (ხელმისაწვდომობის რეჟიმი, გადატვირთვის რეჟიმი).
  11. დააჭირეთ საბოლოო წერტილები ჩანართზე გადადით და გადახედეთ საბოლოო წერტილის კონფიგურაციას.
  12. დააჭირეთ სარეზერვო ასლის პარამეტრები ჩანართი და დააკონფიგურირეთ სარეზერვო ასლის პრიორიტეტები.
  13. დააჭირეთ მსმენელი ჩანართი და სურვილისამებრ შექმენით მსმენელი.
  14. დაწკაპეთ შემდეგი და აირჩიეთ მონაცემთა სინქრონიზაციის მეთოდი.
  15. გადახედეთ ვალიდაციის შედეგებს და მოაგვარეთ ნებისმიერი პრობლემა.
  16. დაწკაპეთ შემდეგი და გადახედეთ შეჯამებას.
  17. დაწკაპეთ ფერი ხელმისაწვდომობის ჯგუფის შესაქმნელად.
  18. აკონტროლეთ პროგრესი და დაადასტურეთ წარმატებული შექმნა.

4.6.2 Transact-SQL-ის გამოყენება

სკრიპტირებადი და განმეორებადი განლაგებისთვის შექმენით ხელმისაწვდომობის ჯგუფები Transact-SQL-ის გამოყენებით.

  1. შექმენით ხელმისაწვდომობის ჯგუფი პირველად რეპლიკაზე:
    CREATE AVAILABILITY GROUP AG_Name
    FOR DATABASE DatabaseName
    REPLICA ON
      'PrimaryServer\Instance' WITH
        (ENDPOINT_URL = 'TCP://PrimaryServer:5022',
         AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
         FAILOVER_MODE = AUTOMATIC,
         SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL)),
      'SecondaryServer\Instance' WITH
        (ENDPOINT_URL = 'TCP://SecondaryServer:5022',
         AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,
         FAILOVER_MODE = AUTOMATIC,
         SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL));
  2. შეაერთეთ მეორადი რეპლიკა ხელმისაწვდომობის ჯგუფში:
    ALTER AVAILABILITY GROUP AG_Name JOIN;
  3. შეუერთდით მეორად მონაცემთა ბაზას:
    ALTER DATABASE DatabaseName SET HADR AVAILABILITY GROUP = AG_Name;

4.6.3 PowerShell-ის გამოყენება

PowerShell უზრუნველყოფს სკრიპტირების შესაძლებლობებს ხელმისაწვდომობის ჯგუფების შესაქმნელად და სამართავად.

  1. შექმენით ხელმისაწვდომობის ჯგუფის ობიექტი:
    $AG = New-SqlAvailabilityGroup -Name "AG_Name" -Path "SQLSERVER:\SQL\PrimaryServer\Instance"
  2. დაამატეთ მონაცემთა ბაზები:
    Add-SqlAvailabilityDatabase -Path "SQLSERVER:\SQL\PrimaryServer\Instance\AvailabilityGroups\AG_Name" -Database "DatabaseName"
  3. დააკონფიგურირეთ რეპლიკები სასურველი თვისებებით New-SqlAvailabilityReplica cmdlet-ის გამოყენებით.
  4. მეორადი რეპლიკების შეერთება Join-SqlAvailabilityGroup cmdlet-ის გამოყენებით.

4.7 რეპლიკების დამატება ხელმისაწვდომობის ჯგუფში

დააკონფიგურირეთ რეპლიკა-სპეციფიკური თვისებები, რომლებიც აკონტროლებენ თითოეული ინსტანციის მონაწილეობას ხელმისაწვდომობის ჯგუფში.

4.7.1 რეპლიკის თვისებების კონფიგურაცია

დააყენეთ თვისებები თითოეული რეპლიკისთვის, რათა განსაზღვროთ მისი როლი და შესაძლებლობები ხელმისაწვდომობის ჯგუფში.

  1. In SQL Server მენეჯმენტის სტუდია, გაფართოება AlwaysOn მაღალი ხელმისაწვდომობა -> ხელმისაწვდომობის ჯგუფები.
  2. გაშალეთ ხელმისაწვდომობის ჯგუფი და შემდეგ გაშალეთ ხელმისაწვდომობის რეპლიკები.
    ხელმისაწვდომობის რეპლიკები SQL Server ყოველთვის ხელმისაწვდომი ჯგუფები
  3. დააწკაპუნეთ მაუსის მარჯვენა ღილაკით რეპლიკაზე და აირჩიეთ განცხადებები.
  4. გადახედეთ და შეცვალეთ კავშირის პარამეტრები ძირითადი და მეორადი როლებისთვის.
  5. საჭიროების შემთხვევაში, დააკონფიგურირეთ სესიის დროის ამოწურვის მნიშვნელობები.
  6. დაწკაპეთ OK ცვლილებების შენახვა.

4.7.2 ხელმისაწვდომობის რეჟიმების დაყენება

რეპლიკებს შორის სინქრონიზაციის ქცევის გასაკონტროლებლად, ხელმისაწვდომობის რეჟიმის კონფიგურაცია.

  1. დააწკაპუნეთ მაუსის მარჯვენა ღილაკით ხელმისაწვდომობის ჯგუფზე და აირჩიეთ განცხადებები.
  2. ამ ზოგადი გვერდზე, გადადით ხელმისაწვდომობის რეპლიკები სექცია.
  3. თითოეული რეპლიკისთვის აირჩიეთ სინქრონული ჩაწერა or ასინქრონული ჩაწერა ჩამოშლადიდან.
  4. სინქრონული დადასტურების გამოყენება ლოკალური მაღალი ხელმისაწვდომობის რეპლიკებისთვის.
  5. გეოგრაფიულად დაშორებული კატასტროფის აღდგენის რეპლიკებისთვის გამოიყენეთ ასინქრონული დადასტურება.
  6. დაწკაპეთ OK კონფიგურაციის შესანახად.

ხელმისაწვდომობის რეპლიკებისთვის ხელმისაწვდომობის რეჟიმების დაყენება

4.7.3 გადართვის რეჟიმების დაყენება

თითოეული რეპლიკისთვის გადართვის რეჟიმის კონფიგურაცია.

  1. დააწკაპუნეთ მაუსის მარჯვენა ღილაკით ხელმისაწვდომობის ჯგუფზე და აირჩიეთ განცხადებები.
  2. ამ ზოგადი გვერდზე, გადადით ხელმისაწვდომობის რეპლიკები სექცია.
  3. სინქრონული commit რეპლიკებისთვის, აირჩიეთ ავტომატური or სახელმძღვანელო გადართვის რეჟიმი.
  4. ავტომატური გადართვა მოითხოვს სინქრონული დადასტურების რეჟიმს და საშუალებას იძლევა უყურადღებოდ დატოვებული გადართვა.
  5. ასინქრონული commit რეპლიკებისთვის ხელმისაწვდომია მხოლოდ ხელით გადართვა.
  6. ავტომატური გადართვისთვის დააკონფიგურირეთ მაქსიმუმ სამი რეპლიკა (ერთი ძირითადი და ორი მეორადი).
  7. დაწკაპეთ OK პარამეტრების გამოყენება.

ხელმისაწვდომობის რეპლიკებისთვის გადამისამართების რეჟიმების დაყენება

4.7.4 სარეზერვო ასლის პარამეტრების კონფიგურაცია

დააყენეთ სარეზერვო ასლის შექმნის პარამეტრები, რათა გააკონტროლოთ, თუ სად უნდა განხორციელდეს სარეზერვო ასლის ოპერაციები.

  1. დააწკაპუნეთ მაუსის მარჯვენა ღილაკით ხელმისაწვდომობის ჯგუფზე და აირჩიეთ განცხადებები.
  2. აირჩიეთ სარეზერვო ასლის პარამეტრები მარცხენა სარკმელზე.
  3. აირჩიეთ ერთ-ერთი სარეზერვო ასლის პარამეტრი:
    • უპირატესობა მიანიჭეთ მეორეხარისხოვანს: სარეზერვო ასლები მეორადზე, თუ შესაძლებელია, წინააღმდეგ შემთხვევაში პირველადზე
    • მხოლოდ მეორადისარეზერვო ასლები მხოლოდ მეორად რეპლიკებზე
    • პირველადისარეზერვო ასლები მხოლოდ პირველად რეპლიკაზე
    • ნებისმიერი რეპლიკა: სარეზერვო ასლები ნებისმიერ ხელმისაწვდომ რეპლიკაზე
  4. დააყენეთ სარეზერვო ასლის პრიორიტეტის მნიშვნელობები თითოეული რეპლიკისთვის (0-100).
  5. უფრო მაღალი პრიორიტეტის მნიშვნელობები მიუთითებს სასურველ სარეზერვო სამიზნეებზე.
  6. დაწკაპეთ OK პარამეტრების შესანახად.

ხელმისაწვდომობის ჯგუფისთვის სარეზერვო ასლის პარამეტრების კონფიგურაცია

4.8 ხელმისაწვდომობის ჯგუფის მსმენელის კონფიგურაცია

შექმენით მსმენელი, რომელიც უზრუნველყოფს ერთი კავშირის წერტილს, რომელიც ავტომატურად გადამისამართდება მიმდინარე პირველად რეპლიკაზე.

4.8.1 მსმენელის შექმნა

კლიენტთან კავშირის მართვისთვის ხელმისაწვდომობის ჯგუფს დაამატეთ მსმენელი.

  1. In SQL Server მენეჯმენტ სტუდია, გააფართოვეთ ხელმისაწვდომობის ჯგუფი.
  2. მარჯვენა ღილაკის ხელმისაწვდომობის ჯგუფის მსმენელები და აირჩიეთ მსმენელის დამატება.
    დაამატეთ მსმენელი ხელმისაწვდომობის ჯგუფში
  3. შეიყვანეთ DNS სახელი მსმენელისთვის (მაგალითად, AG_Listener).
  4. შეიყვანეთ პორტის ნომერი (ნაგულისხმევია 1433).
  5. აირჩიეთ სტატიკური IP ქსელის რეჟიმისთვის.
  6. დაწკაპეთ დამატება თითოეული ქვექსელისთვის IP მისამართის დასამატებლად.
  7. შეიყვანეთ IP მისამართი და აირჩიეთ ქვექსელი.
  8. დაწკაპეთ OK მსმენელის შესაქმნელად.
  9. დარწმუნდით, რომ Listener გამოჩნდება Object Explorer-ში და არის ონლაინ რეჟიმში.

4.8.2 DNS და IP პარამეტრების კონფიგურაცია

გადაამოწმეთ DNS რეგისტრაცია და ქსელის კონფიგურაცია მსმენელისთვის.

  1. გახსენით DNS მენეჯერი დომენის კონტროლერზე.
  2. გადაამოწმეთ, რომ მსმენელის სახელი რეგისტრირებულია ყველა IP მისამართზე.
  3. კლიენტის მანქანებიდან DNS გარჩევადობის ტესტირება:
    nslookup ListenerName
  4. დარწმუნდით, რომ ყველა კონფიგურირებული IP მისამართი დაბრუნებულია.
  5. Failover Cluster Manager-ში გაშალეთ როლები და აირჩიეთ ხელმისაწვდომობის ჯგუფი.
  6. შეამოწმეთ, რომ IP მისამართის რესურსები ონლაინშია.
  7. შეამოწმეთ, რომ ქსელის სახელის რესურსი ონლაინშია.
    გადაამოწმეთ მსმენელის IP მისამართი და ქსელის სახელის რესურსი.

4.8.3 მსმენელის კავშირის ტესტირება

დარწმუნდით, რომ კლიენტის აპლიკაციებს შეუძლიათ დაკავშირება მსმენელის მეშვეობით.

  1. კლიენტის მოწყობილობიდან, გახსენით SQL Server მენეჯმენტის სტუდია.
  2. დაკავშირება სერვერის სახელის ნაცვლად მსმენელის სახელის გამოყენებით.
  3. შეასრულეთ მოთხოვნა მიმდინარე პირველადი რეპლიკასთან კავშირის დასადასტურებლად:
    SELECT @@SERVERNAME;
  4. წაკითხვის განზრახვის მარშრუტიზაციის შესამოწმებლად, კავშირის სტრიქონში ApplicationIntent=ReadOnly-ს დამატებით.
  5. გადაამოწმეთ კავშირის გადამისამართებები წაკითხვად მეორად რეპლიკაზე.
  6. ხელმისაწვდომობის ჯგუფის ხელით გადამოწმებით და ხელახლა დაკავშირების დადასტურებით, შეამოწმეთ ჩავარდნის პროცესი.

4.9 მონაცემთა სინქრონიზაციის მეთოდები

აირჩიეთ მონაცემთა სინქრონიზაციის მეთოდი მეორადი რეპლიკების მონაცემთა ბაზის ასლებით ინიციალიზაციისთვის.

4.9.1 ავტომატური დათესვა

ავტომატური დათესვა მონაცემთა ბაზის მონაცემებს ქსელში გადასცემს ხელით სარეზერვო ასლების შექმნისა და აღდგენის გარეშე.

  1. ხელმისაწვდომობის ჯგუფის შექმნისას, აირჩიეთ ავტომატური დათესვა როგორც სინქრონიზაციის მეთოდი.
    ავტომატური დათესვა ხელმისაწვდომობის ჯგუფში
  2. უზრუნველყავით ქსელური კავშირი და საკმარისი გამტარუნარიანობა რეპლიკებს შორის.
  3. პირველადი რეპლიკა ავტომატურად გადასცემს მონაცემთა ბაზის მონაცემებს მეორად რეპლიკებში.
  4. დათესვის პროგრესის მონიტორინგი ხელმისაწვდომობის ჯგუფის დაფის ან DMV-ების გამოყენებით.
  5. ავტომატური დათესვა მოითხოვს SQL Server 2016 ან უფრო გვიან.
  6. დიდი მონაცემთა ბაზებისთვის, გაითვალისწინეთ ქსელის გავლენა და გრაფიკი დაბალი გამოყენების პერიოდებში.

4.9.2 ხელით დათესვა (სარეზერვო ასლის შექმნა და აღდგენა)

ხელით დათესვა გულისხმობს პირველადზე სარეზერვო ასლების შექმნას და მეორად რეპლიკებზე მათ აღდგენას.

  1. პირველად რეპლიკაზე, შექმენით სრული სარეზერვო ასლი:
    BACKUP DATABASE DatabaseName TO DISK = '\\SharePath\DatabaseName.bak';
  2. შექმენით ტრანზაქციების ჟურნალის სარეზერვო ასლი:
    BACKUP LOG DatabaseName TO DISK = '\\SharePath\DatabaseName.trn';
  3. თითოეულ მეორად რეპლიკაზე აღადგინეთ სრული სარეზერვო ასლი:
    RESTORE DATABASE DatabaseName FROM DISK = '\\SharePath\DatabaseName.bak' WITH NORECOVERY;
  4. ჟურნალის სარეზერვო ასლის აღდგენა:
    RESTORE LOG DatabaseName FROM DISK = '\\SharePath\DatabaseName.trn' WITH NORECOVERY;
  5. შეუერთდით მონაცემთა ბაზას ხელმისაწვდომობის ჯგუფში:
    ALTER DATABASE DatabaseName SET HADR AVAILABILITY GROUP = AG_Name;
  6. დარწმუნდით, რომ სინქრონიზაცია დაიწყო და მონაცემთა ბაზა სინქრონიზებული მდგომარეობისკენ წავიდა.

4.9.3 მონაცემთა ბაზის სნეპშოტის ფაილები

გამოიყენეთ მონაცემთა ბაზის სნეპშოტის ფაილები არსებული მონაცემთა ბაზის ფაილებიდან მეორადი რეპლიკების ინიციალიზაციისთვის.

  1. მონაცემთა ბაზის გამოყოფა ან სარეზერვო ასლის შექმნა ძირითად რეპლიკაზე.
  2. დააკოპირეთ მონაცემთა ბაზის ფაილები თითოეულ მეორად რეპლიკაში იმავე ფაილის ბილიკების გამოყენებით.
  3. მეორად რეპლიკებზე, მიამაგრეთ მონაცემთა ბაზა ან აღადგინეთ აღდგენის გარეშე.
  4. დარწმუნდით, რომ მონაცემთა ბაზა აღდგენის მდგომარეობაშია.
  5. შეუერთდით მონაცემთა ბაზას ხელმისაწვდომობის ჯგუფს.
  6. ეს მეთოდი სასარგებლოა ძალიან დიდი მონაცემთა ბაზებისთვის, სადაც ქსელური გადაცემა არაპრაქტიკული იქნება.

5. კითხვა

5.1 ზოგადი კითხვები

კითხვა: რა განსხვავებაა Always On FCI-სა და Always On AG-ს შორის?

A: Always On Failover Cluster-ის ინსტანციები უზრუნველყოფენ ინსტანციის დონის მაღალ ხელმისაწვდომობას საერთო საცავის გამოყენებით, ხოლო Always On Availability Groups უზრუნველყოფს მონაცემთა ბაზის დონის მაღალ ხელმისაწვდომობას საერთო საცავის გარეშე. AG გთავაზობთ წაკითხვად მეორად ფაილებს და უფრო მოქნილ გეოგრაფიულ განაწილებას.

კითხვა: შემიძლია გამოვიყენო Always On Availability ჯგუფები? SQL Server სტანდარტული გამოცემა?

დიახ, SQL Server 2016 წლის სტანდარტული გამოცემა და უფრო გვიანდელი ვერსიები მხარს უჭერს ძირითად ხელმისაწვდომობის ჯგუფებს შეზღუდვებით, მათ შორის ერთი მონაცემთა ბაზა თითო AG-ზე, მაქსიმუმ ორი რეპლიკა და წასაკითხი მეორადი მხარდაჭერის არარსებობა.

კითხვა: მჭირდება თუ არა საერთო საცავი ყოველთვის ჩართული ხელმისაწვდომობის ჯგუფებისთვის?

A: არა, ხელმისაწვდომობის ჯგუფები არ საჭიროებენ საერთო საცავს. თითოეული რეპლიკა ინახავს მონაცემთა ბაზების დამოუკიდებელ ასლებს ადგილობრივ საცავში, რომლებიც სინქრონიზებულია ტრანზაქციების ჟურნალის გადაზიდვის გზით.

კითხვა: რა არის რეპლიკების მაქსიმალური რაოდენობა ხელმისაწვდომობის ჯგუფში?

A: SQL Server Enterprise Edition მხარს უჭერს ცხრა რეპლიკას (ერთი ძირითადი და რვა მეორადი). განაწილებულ ხელმისაწვდომობის ჯგუფებს შეუძლიათ მხარი დაუჭირონ სულ 18 რეპლიკას ორ ხელმისაწვდომობის ჯგუფში.

5.2 კონფიგურაციის კითხვები

კითხვა: როგორ ავირჩიო სინქრონული და ასინქრონული კომიტი რეჟიმები?

A: გამოიყენეთ სინქრონული დადასტურება ნულოვანი მონაცემთა დაკარგვის მოთხოვნებისთვის იმავე მონაცემთა ცენტრში ან დაბალი შეყოვნების მქონე ქსელებში. გამოიყენეთ ასინქრონული დადასტურება შორეული კატასტროფის აღდგენის რეპლიკებისთვის, სადაც სინქრონული დადასტურება გავლენას მოახდენს მუშაობაზე.

კითხვა: შემიძლია თუ არა სინქრონული და ასინქრონული რეპლიკების შერევა ერთსა და იმავე ხელმისაწვდომობის ჯგუფში?

A: დიახ, ხელმისაწვდომობის ჯგუფები მხარს უჭერენ შერეულ კონფიგურაციებს როგორც სინქრონული, ასევე ასინქრონული რეპლიკებით. ეს უზრუნველყოფს ლოკალურ მაღალ ხელმისაწვდომობას სინქრონული რეპლიკებით და დისტანციურ კატასტროფის შემდგომ აღდგენას ასინქრონული რეპლიკებით.

კითხვა: რა ხდება ჩემს კავშირებთან გადართვის დროს?

A: არსებული კავშირები წყდება, როდესაც ხდება გადართვა. აპლიკაციები, რომლებსაც აქვთ კავშირის ხელახალი ცდის ლოგიკა, ავტომატურად უერთდებიან ახალ ძირითად მოწყობილობას მსმენელის მეშვეობით. გადართვის პროცესი, როგორც წესი, სრულდება წამებში ან წუთებში.

კითხვა: საჭიროა თუ არა ლოგინისა და დავალებების სინქრონიზაცია რეპლიკებს შორის?

_ შიგნით SQL Server 2019 და უფრო ადრეული ვერსიები, დიახ - შესვლები, SQL Agent-ის დავალებები და დაკავშირებული სერვერები ხელით უნდა იყოს სინქრონიზებული. SQL Server 2022 წელს წარმოგიდგენთ შეკავებული ხელმისაწვდომობის ჯგუფებს, რომლებიც ავტომატურად მოიცავს ამ ობიექტებს.

5.3 მენეჯმენტის საკითხები

კითხვა: შემიძლია სარეზერვო ასლების შექმნა მეორად რეპლიკებზე?

A: დიახ, მეორადი რეპლიკები მხარს უჭერენ სრულ, დიფერენციალურ და ტრანზაქციების ჟურნალის სარეზერვო ასლებს. დააკონფიგურირეთ სარეზერვო ასლების პარამეტრები, რათა სარეზერვო ასლები პირველადი რეპლიკიდან გადმოიტვირთოს და მისი რესურსების გამოყენება შემცირდეს.

კითხვა: როგორ გავაკეთო პატჩი SQL Server მინიმალური შეფერხებით?

A: გამოიყენეთ მოძრავი განახლებები ჯერ მეორადი რეპლიკების პატჩით, შემდეგ ხელით გადამისამართებით პატჩირებულ მეორეხარისხოვანზე და ბოლოს წინა პირველადი სისტემის პატჩით. ეს მინიმუმამდე ამცირებს გადამისამართების ხანგრძლივობის შეფერხების დროს.

კითხვა: შემიძლია მონაცემთა ბაზების დამატება არსებულ ხელმისაწვდომობის ჯგუფში?

A: დიახ, მონაცემთა ბაზების დამატება შესაძლებელია მიმდინარე ხელმისაწვდომობის ჯგუფებში. მონაცემთა ბაზა უნდა იყოს სრული აღდგენის მოდელში სრული სარეზერვო ასლით, ხოლო მეორადი რეპლიკები უნდა იყოს დათესილი ავტომატური დათესვის ან ხელით სარეზერვო ასლის შექმნისა და აღდგენის გამოყენებით.

კითხვა: რა არის ავტომატური დათესვა და უნდა გამოვიყენო თუ არა ის?

A: ავტომატური დათესვა მონაცემთა ბაზის მონაცემებს ქსელში გადასცემს მეორადი რეპლიკების ინიციალიზაციისთვის ხელით სარეზერვო ასლების შექმნის გარეშე. გამოიყენეთ ის მცირე მონაცემთა ბაზებისთვის ან როდესაც ქსელის გამტარუნარიანობა საკმარისია. ძალიან დიდი მონაცემთა ბაზებისთვის, ხელით დათესვა შეიძლება უფრო სწრაფი იყოს.

კ: სად უნდა გავუშვა DBCC CHECKDB ხელმისაწვდომობის ჯგუფში?

A: პირველადი რეპლიკაზე დატვირთვის შესამცირებლად, DBCC CHECKDB უნდა გაუშვათ მეორად რეპლიკებზე. მონაცემთა ბაზის თანმიმდევრულობის შემოწმებები შეიძლება შესრულდეს მეორად მონაცემთა ბაზებზე პირველადი რეპლიკაზე გავლენის მოხდენის გარეშე.

DBCC CHECKDB-ის შესახებ დამატებითი ინფორმაციისთვის იხილეთ ჩვენი ყოვლისმომცველი სახელმძღვანელო.

5.4 პრობლემების გადაჭრის კითხვები

კითხვა: რატომ არის ჩემი მონაცემთა ბაზა არასინქრონიზებულ მდგომარეობაში?

A: გავრცელებული მიზეზებია ქსელთან დაკავშირების პრობლემები, მონაცემთა გადაადგილების შეჩერება, მეორად რეპლიკებზე დისკზე არასაკმარისი სივრცე ან საბოლოო წერტილის პრობლემები. შეამოწმეთ სინქრონიზაციის მდგომარეობის აღწერა და SQL Server შეცდომების ჟურნალები კონკრეტული დეტალებისთვის. თუ მეორად მონაცემთა ბაზაში შევიდა აღდგენის მდგომარეობა ან შოუები აღდგენა მოლოდინშია, მიზნობრივი შესწორებების სანახავად იხილეთ ბმულზე მოცემული სახელმძღვანელოები.

კითხვა: როგორ ავიძულო გადართვა, როდესაც ძირითადი პორტი მიუწვდომელია?

A: დაუკავშირდით მეორად რეპლიკას და შეასრულეთ ALTER AVAILABILITY GROUP AG_Name FORCE_FAILOVER_ALLOW_DATA_LOSS. ეს ადასტურებს მონაცემთა პოტენციურ დაკარგვას და მეორად რეპლიკას დაუყოვნებლივ გადაჰყავს პირველადი.

კითხვა: რატომ არ შეუძლიათ კლიენტებს ჩემს მსმენელთან დაკავშირება?

A: გადაამოწმეთ, რომ მსმენელი ონლაინ რეჟიმშია Failover Cluster Manager-ში, DNS რეგისტრაცია წარმატებით შესრულდა, ყველა მსმენელის IP მისამართი ხელმისაწვდომია კლიენტებისთვის და firewall-ის წესები მსმენელის პორტზე ტრაფიკის გადაცემის საშუალებას იძლევა.

კითხვა: რას ნიშნავს დიდი გამეორების რიგი?

A: დიდი გამეორების რიგი მიუთითებს, რომ მეორად რეპლიკას არ შეუძლია ჟურნალის ჩანაწერების გამოყენება მათი მიღების სისწრაფით. ეს შეიძლება მიუთითებდეს დისკის შეყვანის/გამოყვანის შეფერხებებზე, CPU შეზღუდვებზე ან მეორადზე მხოლოდ წაკითხვის მოთხოვნების დაბლოკვაზე.

კითხვა: რა უნდა გავაკეთო, თუ კატასტროფა გავლენას ახდენს ყველა რეპლიკაზე და ჩემი სარეზერვო ასლებიც დაზიანებულია?

A: ეს ყველაზე უარესი სცენარი, თუმცა უკიდურესად იშვიათია, შეიძლება მოხდეს გამოსასყიდის მოთხოვნით განხორციელებული შეტევების, შენახვის ფართომასშტაბიანი ჩავარდნების ან კასკადური კატასტროფების გამო. თქვენი ძირითადი დაცვა პრევენციაა: შეინარჩუნეთ გეოგრაფიულად განაწილებული რეპლიკები, შეინახეთ სარეზერვო ასლები ცალკეულ ადგილებში და
რეგულარულად შეამოწმეთ თქვენი კატასტროფის აღდგენის პროცედურები. თუ ყველა სტანდარტული აღდგენის ვარიანტი ვერ მოხერხდა, სპეციალიზებული SQL მონაცემთა აღდგენის ინსტრუმენტი გადაუდებელი შემთხვევის სახით, შეგიძლიათ სცადოთ მონაცემების ამოღება დაზიანებული MDF ფაილებიდან.

5.5 ლიცენზირებასთან და ხარჯებთან დაკავშირებული კითხვები

კითხვა: როგორ ლიცენზირდება Always On Availability Groups?

A: SQL Server ლიცენზირება დამოკიდებულია გამოცემასა და განლაგების მოდელზე. Enterprise Edition-ის ხელმისაწვდომობის ჯგუფები ყველა რეპლიკაზე Enterprise ლიცენზიებს მოითხოვს. პასიური მეორადი რეპლიკები გარკვეულ პირობებში შეიძლება უფასო ლიცენზირების უფლებით სარგებლობის უფლებას იღებდეს.

კითხვა: შემიძლია გამოვიყენო SQL Server დეველოპერის ვერსია ხელმისაწვდომობის ჯგუფებისთვის?

A: დიახ, დეველოპერის გამოცემა მოიცავს Enterprise Edition-ის ყველა ფუნქციას, მათ შორის სრული ხელმისაწვდომობის ჯგუფების მხარდაჭერას. თუმცა, ის ლიცენზირებულია მხოლოდ შემუშავებისა და ტესტირებისთვის და არა საწარმოო გამოყენებისთვის.

კითხვა: საჭიროებს თუ არა წასაკითხი მეორადი ფაილები დამატებით ლიცენზიებს?

A: ლიცენზირება სცენარზეა დამოკიდებული. კატასტროფის შემდეგ აღდგენისთვის პასიურ მეორად მოწყობილობებს, როგორც წესი, ლიცენზიები არ სჭირდებათ. აქტიურ მეორად მოწყობილობებს, რომლებიც მხოლოდ წასაკითხ სამუშაო დატვირთვას ემსახურებიან, როგორც წესი, ლიცენზიები სჭირდებათ, თუმცა კონკრეტული პირობები განსხვავებულია.

კითხვა: არსებობს თუ არა მაღალი ხელმისაწვდომობის მიღების უფასო გზა? SQL Server?

A: SQL Server Express Edition არ უჭერს მხარს ხელმისაწვდომობის ჯგუფებს. SQL Server სტანდარტული გამოცემა მხარს უჭერს ძირითადი ხელმისაწვდომობის ჯგუფებს, დაწყებული SQL Server 2016 წელს, რაც უზრუნველყოფდა ძირითად მაღალ ხელმისაწვდომობას სტანდარტული გამოცემის ლიცენზირების ფასად.

კითხვა: რა არის განაწილებული ხელმისაწვდომობის ჯგუფები?

A: განაწილებული ხელმისაწვდომობის ჯგუფები ხელმისაწვდომობის ჯგუფის განსაკუთრებული ტიპია, რომელიც მოიცავს ორ ცალკეულ ხელმისაწვდომობის ჯგუფს, რაც საშუალებას იძლევა შეიქმნას სცენარები, რომლებიც აღემატება ტრადიციული ხელმისაწვდომობის ჯგუფების შესაძლებლობებს. წარმოდგენილია SQL Server 2016 წელს, განაწილებული ხელმისაწვდომობის ჯგუფები ითვალისწინებს მასშტაბირებისა და გეოგრაფიული განაწილების მოთხოვნებს.

6. დასკვნა

6.1 ძირითადი პუნქტების შეჯამება

SQL Server Always On Availability Groups წარმოადგენს Microsoft-ის პრემიერ მაღალი ხელმისაწვდომობისა და კატასტროფების აღდგენის გადაწყვეტას მისიის კრიტიკული მონაცემთა ბაზებისთვის. ისინი უზრუნველყოფენ მონაცემთა ბაზის დონის გადართვას საერთო შენახვის მოთხოვნების გარეშე, წაკითხვად მეორად რეპლიკებს სამუშაო დატვირთვების განტვირთვისთვის და მოქნილ გეოგრაფიულ განაწილებას მონაცემთა ყოვლისმომცველი დაცვისთვის. ორგანიზაციებისთვის, რომლებიც ჯერ კიდევ ახორციელებენ ისეთ გადაწყვეტილებებს, როგორიცაა მორების გადაზიდვა or რეპლიკაცია, ხელმისაწვდომობის ჯგუფები გვთავაზობენ უფრო სტაბილურ და ოპერატიულად მარტივ განახლების გზას.

6.2 როდის გამოვიყენოთ ყოველთვის ჩართული ხელმისაწვდომობის ჯგუფები

აირჩიეთ ხელმისაწვდომობის ჯგუფები, როდესაც გჭირდებათ მონაცემთა ბაზის დონის მაღალი ხელმისაწვდომობა ავტომატური გადართვის შესაძლებლობებით. ორგანიზაციები, რომლებსაც სჭირდებათ მონაცემთა ნულოვანი დაკარგვისგან დაცვა კრიტიკული მონაცემთა ბაზებისთვის, სარგებლობენ სინქრონული დადასტურების რეპლიკებით ავტომატური გადართვის შესაძლებლობებით. აპლიკაციები, რომლებიც საჭიროებენ წაკითხვის მასშტაბის შესაძლებლობებს, იყენებენ წაკითხვად მეორად რეპლიკებს შეკითხვის სამუშაო დატვირთვების გასანაწილებლად.

6.3 თქვენი იმპლემენტაციის დაწყება

ხელმისაწვდომობის ჯგუფის დაგეგმვა დაიწყეთ ბიზნეს მოთხოვნების შეფასებით, მათ შორის RTO-ს, RPO-ს და ბიუჯეტის შეზღუდვების. დოკუმენტირება მოახდინეთ მონაცემთა ბაზის მიმდინარე ინფრასტრუქტურის, აპლიკაციების დამოკიდებულებების და ხელმისაწვდომობის მაღალი ხარვეზების შესახებ. შეიმუშავეთ ხელმისაწვდომობის ჯგუფის არქიტექტურა, რომელიც დააკმაყოფილებს მოთხოვნებს რესურსების შეზღუდვების დაცვით.

ლიტერატურა


ავტორის შესახებ

იუან შენგი არის მონაცემთა ბაზის უფროსი ადმინისტრატორი (DBA) 10 წელზე მეტი გამოცდილებით SQL Server გარემოსა და საწარმოს მონაცემთა ბაზის მართვაში. მან წარმატებით გადაჭრა მონაცემთა ბაზის აღდგენის ასობით სცენარი ფინანსურ სერვისებში, ჯანდაცვისა და წარმოების ორგანიზაციებში.

იუანი სპეციალიზირებულია SQL Server მონაცემთა ბაზის აღდგენა, მაღალი ხელმისაწვდომობის გადაწყვეტილებები და მუშაობის ოპტიმიზაცია. მისი ფართო პრაქტიკული გამოცდილება მოიცავს მრავალტერაბაიტიანი მონაცემთა ბაზების მართვას, Always On Availability Groups-ის დანერგვას და კრიტიკულად მნიშვნელოვანი ბიზნეს სისტემებისთვის ავტომატური სარეზერვო ასლისა და აღდგენის სტრატეგიების შემუშავებას.

თავისი ტექნიკური ექსპერტიზისა და პრაქტიკული მიდგომის წყალობით, იუანი ფოკუსირებულია ყოვლისმომცველი სახელმძღვანელოების შექმნაზე, რომლებიც მონაცემთა ბაზის ადმინისტრატორებსა და IT სპეციალისტებს დაეხმარება რთული საკითხების გადაჭრაში. SQL Server ეფექტურად უწევს გამოწვევებს. ის მუდმივად ადევნებს თვალყურს უახლეს ამბებს SQL Server რელიზები და Microsoft-ის განვითარებადი მონაცემთა ბაზის ტექნოლოგიები, რეგულარულად ამოწმებს აღდგენის სცენარებს იმის უზრუნველსაყოფად, რომ მისი რეკომენდაციები ასახავდეს რეალურ სამყაროს საუკეთესო პრაქტიკას.

გაქვთ შეკითხვები SQL Server აღდგენა ან გჭირდებათ დამატებითი რჩევები მონაცემთა ბაზის პრობლემების მოგვარებაში? იუანი სიამოვნებით მოგმართავთ. გამოხმაურება და წინადადებები ამ ტექნიკური რესურსების გასაუმჯობესებლად.

გააზიარე ახლა: