Групи доступності alwayson і завдання sql server: збереження узгодженості пакетів

Відео: Підтримка великих БД на MS SQL Server

Зрозуміло, мета синхронізації насамперед в тому і полягає, щоб у випадках, коли адміністратор використовує пакети SSIS для управління резервними копіями або коли ці пакети виконуються в якості пакетних завдань (див. Статтю «Визначення пакетних завдань»), забезпечувати контроль не тільки за тим , щоб завдання були ідентичні на всіх серверах, де розміщаються групи доступності (тобто щоб при їх виконанні виконувалися ідентичні логіка, наслідки або операції), а й за тим, щоб згадані завдання або операції виконувалися тільки на цільової або кращою репліці. У попередній статті йшлося про те, як можна з легкістю доповнювати пакети SSIS логічними конструкціями, що дозволяють здійснювати перевірки на виконання умов, щоб забезпечувати виконання тих чи інших операцій тільки на відповідному сервері. Крім того, вище я навів кілька посилань і інформацію про те, як здійснювати первинну синхронізацію пакетів або синхронізацію в ручному режимі при внесенні змін до той чи інший пакет.

Але в разі, коли основна логічна конструкція або операції розміщуються на декількох серверах, виникає проблема збереження узгодженості цих пакетів або завдань. Для ілюстрації наведемо таку ситуацію. Припустимо, ви налаштували групи доступності для забезпечення високої доступності або відновлення після збою, але в той же час у вас є група сховищ даних, в яких регулярно виконуються процеси вилучення, перетворення і завантаження даних з використанням контенту ключових баз даних. В цьому випадку необхідно не тільки подбати про те, щоб вилучення даних здійснювалося з ідеальних або бажаних реплік, тобто перенесення цього процесу на репліки, призначені тільки для читання, на першому етапі, можливо, видається цілком логічним - якщо не брати до уваги проблем ліцензування та логіки «підтримки актуальності» операцій записи, які, можливо, в кінці кінців будуть використовуватися. Додатково до цього вам потрібно забезпечити нормальне функціонування системи у разі, коли, скажімо, молодший розробник ETL вносить деякі зміни в пакет і викладає ці зміни тільки на сервер, де розміщується, припустимо, головна репліка однієї з ваших баз даних, що входять до складу групи доступності . Якщо така ситуація дійсно виникне, то в той момент, коли відбудеться аварійне перемикання на інший хост, трапиться одне з двох. Або знову доданий завдання, викладене розробником, не виконуватиметься на новому сервері, або - якщо внесене в пакет SSIS відповідне «зміна» є модифікацією існуючого пакету - під час виконання до нової репліці будуть застосовані старий пакет або колишня логіка.





Зрозуміло, жоден з перерахованих варіантів не дає результату, навіть віддалено нагадує той, який вам потрібен. Звичайно, ви можете створити політику або контрольний список заходів, які слід застосовувати щоразу, коли запускаються пакети SSIS, але ... Сподіваюся, ви не вважаєте мене безнадійним скептиком, якщо я висловлю сумнів в тому, що такий процес буде виконуватися бездоганно щоразу . Тому я пропоную вашій увазі наступний сценарій- можете регулярно використовувати його для опитувань (або перевірок) пакетів SSIS, незалежно від того, чи йде мова про звичайні пакетних завданнях SSIS або про пакетах SSIS, використовуваних в роботі з планами обслуговування, і для звітів по будь-яких проблем синхронізації.




Важливо відзначити, що наведений код призначений виключно для перевірок планів обслуговування - звідси і його назва. І, як зазначалося в попередній статті, якщо ви використовуєте плани обслуговування для роботи з будь-якими іншими об`єктами, крім резервних копій, саме час ще раз замислитися над тим, що ви, власне, робите. А якщо ви використовуєте плани обслуговування для роботи з резервними копіями, вам, можливо, варто взяти на озброєння сценарій, який я пропонував в попередній статті. Майте на увазі, що код в лістингу може служити довідковим матеріалом за деякими типами логічних конструкцій, які ви можете використовувати або для роботи з окремими типами пакетів SSIS (обумовленими по іменах або розташування), або для виконання перевірок у всіх пакетах SSIS, якщо в тому виникне необхідність. А для того, щоб отримати уявлення про те, як використовуються описані вище логічні конструкції для проведення регулярних перевірок синхронізації, вам буде корисно переглянути і перечитати попередні статті серії, де викладаються основні принципи таких перевірок, а також наводиться ряд конкретних прикладів їх реалізації. Що ж стосується інших аспектів проблеми, прошу вас мати на увазі, що, кажучи тут про завдання синхронізації SSIS, я демонструю всього лише верхівку айсберга. Якщо завгодно, вам пропонується опис підходу до вирішення питання в найзагальнішому вигляді. Використовуючи цей підхід в робочих середовищах, я домагався значних успіхів. Але при цьому мені доводилося стикатися і з труднощами, і зі збоями. У багатьох випадках пакети SSIS можуть бути до абсурдного складними (а також нестійкими і «ламкими»). Таким чином, навіть якщо подані на різних серверах екземпляри пакета ідентичні, з цього зовсім не випливає, що пакет SSIS завжди буде виконуватися на сервері, де він не був протестований (просто тому, що деталі підключення, шляхи до файлів або папок (або ж правила безпеки, керуючі доступом до цих шляхах) можуть бути абсолютно іншими або не на 100% синхронізованими). В цілому, якщо ви використовуєте пакети SSIS в поєднанні з базами даних груп доступності, обов`язково прослідкуйте за тим, щоб при підключенні до баз даних груп доступності використовувалися прослуховувачі груп доступності, а також переконайтеся в тому, що в пакетах застосовується відповідна логіка if / else ( або що ви просто активуєте і деактівіруете завдання по мірі необхідності). І ще одне зауваження: єдиний спосіб забезпечити виконання перерахованих вище пунктів - за допомогою тестування. Але ця процедура напевно вже стала для вас звичною, після того як у вашому середовищі з`явилися групи доступності.


Далі ми обговоримо деякі міркування, що стосуються структур, які не вкладаються в схему «простих двовузлового» топологій груп доступності, і розглянемо інші підходи до тем і завдань, про які я писав в раніше опублікованих статтях.

---

Все, що вам слід зрозуміти з цієї статті - для SQL Server необхідний надійний сервер! І виділені сервера від Friendhosting (https://friendhosting.net/dedicated.php) ідеально підходить для цієї мети! Дізнайтеся подробиці прямо зараз на friendhosting.net.