Чи змінюють схему «ламають» групи доступності чи вони обробляються прозоро?

Моя організація планує прийняти групи доступності SQL Server 2012, і я намагаюся зрозуміти, який вплив (якщо такий є) матиме на процес оновлення додатків.

Ми випускаємо оновлення програми на 8-тижневому циклі, і будь-який випуск може включати зміни схеми та / або міграцію даних.

Я намагаюся зрозуміти, чи обробляє рішення HA / DR прозора зміна схеми (нові стовпці, індекси додаються у вторинники) або необхідне вручну втручання, щоб створити схему для кожного примірника, а потім увімкнути Завжди ввімкнено.

Я припускаю, що деталь міграції даних обробляється прозоро, але я також хотів би підтвердити це.

Я думаю, що я також роблю припущення про те, що в цій поведінці немає різниці на основі конфігурації груп доступності, яка може бути помилковою. Будь ласка, дай мені знати.

Коротко; У будь-якому даному випуску моєї програми я можу змінити дуже велику таблицю (від 10 до 100 мільйонів записів), додавши до неї стовпці. Деякі стовпці можуть бути "чисто новими", щоб вони могли використовувати функцію зміни схеми Enterprise Online. Інші стовпці можуть бути рефакторинг існуючого стовпця (FullName розбивається на FirstName та LastName), і міграція буде виконуватися для кожного рядка таблиці для заповнення цих полів. Чи вимагає будь-якого з цих способів поведінки DBA змінити конфігурацію AlwaysOn або це обробляється за замовчуванням, і всі вторинні отримують заяви DDL та DML "безкоштовно"?

Дякуємо за будь-яку чіткість, яку ви можете надати.

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

Де ви можете бути обережними, це коли у вас є додаток, який вказує на основний, і ви оновите його, щоб відповідати змінам схеми. Але у вас може бути інша програма, яка вказує на другорядну (наприклад, з наміром лише для читання), і цю зміну додатку потрібно синхронізувати.

Інший потенціал є, коли ваша база даних, що входить до групи доступності, має посилання на об'єкти в інших базах даних (наприклад, статичну таблицю пошуку, яка зберігається в базі даних утиліт). Якщо ці зміни змінюються і АГ залежить від цих об'єктів, вам доведеться натиснути ці зміни вручну. Те ж саме стосується завдань, входу на рівні сервера, пов'язаних серверів тощо - все, що живе за межами бази даних та / або не є оперативно можливим. Користувачі баз даних можуть осиротіти (містять користувачів убік). Я знаю, що це, мабуть, очевидно, але хотілося чітко перерахувати його для повноти.

Більше відповідей тут від Remus, користувачі просять, можливо, видалити запити із вторинної репліки та перевірити стан повторного розміру черги в таблиці: sys.dm_hadr_database_replica_states AlwaysOn DDL та Chama Changes