Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности

Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
06.03.2018, 17:39
|
|||
|---|---|---|---|
Отработка отказа в AlwaysOn |
|||
|
#18+
Добрый день! Задача: протестировать работу AlwaysOn при отказе. Дано: Настроенный синхронный AlwaysOn в виндовом Failover кластере, одна база, синхронизирована, вторая нода настроена на чтение (ApplicationIntent=ReadOnly) Сценарий проверки: рушится кластер (первая нода при этом работает и там теоретически возможны транзакции), поднимаем AlwaysOn на второй ноде с возможной потерей данных, работаем там, поднимаем обратно кластер, возвращаемся на первую ноду с потерей данных на первой ноде. При реализации сценария упираемся в проблему на этапе возврата на первую ноду с потерей на них данных. Ситуация видна на приложенной картинке. Первая нода разсинхронизирована. Как её синхронизировать обратно - непонятно. Выводить базу из AlwaysOn и обратно добавлять синхронизируя с нуля - неспортивно (на продакшене это займет несколько суток). Нашел такую доку , там пишут: Код: sql 1. 2. 3. 4. 5. Однако этого не произошло. Как можно повторно синхронизировать первую ноду данными со второй не ломая AlwaysOn и не выводя из него базы? В технологии новички, не пинайте сильно. Если кините докой, буду благодарен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
06.03.2018, 17:44
|
|||
|---|---|---|---|
|
|||
Отработка отказа в AlwaysOn |
|||
|
#18+
После того, как сделали failover с потрей данных -- только с нуля. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
06.03.2018, 17:55
|
|||
|---|---|---|---|
Отработка отказа в AlwaysOn |
|||
|
#18+
Гавриленко Сергей АлексеевичПосле того, как сделали failover с потрей данных -- только с нуля. Печально... Общая постановка задачи: из строя выходит первая нода вместе со свидетелем кластера. необходимо уехать на вторую ноду, работать там, а при восстановлении первой ноды и свидетеля вернуться обратно с теми данными, что появились на второй ноде за время простоя. Может мы изначально неправильно проблему решали? Может можно обойтись без поднятия AlwaysOn на второй ноде с возможной потерей данных? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
06.03.2018, 18:00
|
|||
|---|---|---|---|
|
|||
Отработка отказа в AlwaysOn |
|||
|
#18+
OblomОбщая постановка задачи: из строя выходит первая нода вместе со свидетелем кластера. необходимо уехать на вторую ноду, работать там, а при восстановлении первой ноды и свидетеля вернуться обратно с теми данными, что появились на второй ноде за время простоя.Если вы хотите сделать, что написали, то достаточно просто поднять базу в AlwaysOn по стандартной процедуре через полный бэкап базы. Если вы вдруг хотите "смержить" две реплики после того, как их расцепили, то нет, сервер этого не умеет и придется делать вручную. Ну и если не хотите таких проблем, включите уже синхронный commit. Не поможет в этом случае, но лучше включить, проблем меньше будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
06.03.2018, 19:22
|
|||
|---|---|---|---|
Отработка отказа в AlwaysOn |
|||
|
#18+
Гавриленко Сергей АлексеевичOblomОбщая постановка задачи: из строя выходит первая нода вместе со свидетелем кластера. необходимо уехать на вторую ноду, работать там, а при восстановлении первой ноды и свидетеля вернуться обратно с теми данными, что появились на второй ноде за время простоя.Если вы хотите сделать, что написали, то достаточно просто поднять базу в AlwaysOn по стандартной процедуре через полный бэкап базы. Если вы вдруг хотите "смержить" две реплики после того, как их расцепили, то нет, сервер этого не умеет и придется делать вручную. Ну и если не хотите таких проблем, включите уже синхронный commit. Не поможет в этом случае, но лучше включить, проблем меньше будет. Понятно, спасибо! А синхронный коммит уже включен, без него автоматический переезд невозможен ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
07.03.2018, 14:51
|
|||
|---|---|---|---|
|
|||
Отработка отказа в AlwaysOn |
|||
|
#18+
Oblomпри восстановлении первой ноды и свидетеля вернуться обратно Вот тут ключевая ошибка. "Померла так померла." После сбоя о ноде можно забыть и если что-то там и починилось, вернуться в кластер она может только в качестве совершенно нового слейва. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|

start [/forum/topic.php?fid=46&tablet=1&tid=1690146]: |
0ms |
get settings: |
8ms |
get forum list: |
16ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
46ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
39ms |
get tp. blocked users: |
1ms |
| others: | 224ms |
| total: | 352ms |

| 0 / 0 |
