Comments 15
Используем AlwaysOn на проекте в режиме Primary — Readable Secondary
Поскольку реплики могут «отставать» в синхронизации, нельзя бездумно отправлять туда все запросы на чтение. Пришлось в приложении самим определять «безопасные» места, в которых можно использовать неактуальные данные. В этих местах запросы на чтение могут идти на реплику.
Поскольку реплики могут «отставать» в синхронизации, нельзя бездумно отправлять туда все запросы на чтение. Пришлось в приложении самим определять «безопасные» места, в которых можно использовать неактуальные данные. В этих местах запросы на чтение могут идти на реплику.
А синхронизация синхронная или асинхронная? Ведь при синхронной не отстают.
Синхронная. Печаль заключается в том, что таки отстают. stackoverflow.com/questions/21161085/sql-server-2012-alwayson-synchronous-replica-is-not-actually-synchronous-for-rea
Кроме того, синхронная плохо подходит в случаях, когда много записей, а машина реплики пишет медленней, чем машина мастера. Тогда при пиковых нагрузках начинает тормозить запись в мастер.
Для нашего проекта я хочу сделать в конечном итоге асинхронную реплику, а также механизм для проверки отставания, чтобы при его росте переставать направлять запросы на реплику.
А вообще, всё это не очень годится для масштабирования. Для отказоустойчивости — да, а при постоянном росте нагрузки и объема данных придётся таки прийти к шардингу. Хотя, многое зависит от проекта…
Кроме того, синхронная плохо подходит в случаях, когда много записей, а машина реплики пишет медленней, чем машина мастера. Тогда при пиковых нагрузках начинает тормозить запись в мастер.
Для нашего проекта я хочу сделать в конечном итоге асинхронную реплику, а также механизм для проверки отставания, чтобы при его росте переставать направлять запросы на реплику.
А вообще, всё это не очень годится для масштабирования. Для отказоустойчивости — да, а при постоянном росте нагрузки и объема данных придётся таки прийти к шардингу. Хотя, многое зависит от проекта…
В нашем проекте запаса аппаратных ресурсов достаточно, а приложения не создают очень сильной нагрузки. Видимо поэтому значительного отставания не наблюдали.
Как планируете реализовать механизм проверки отставания, полностью свой или есть какие-то механизмы в MS SQL?
Согласен, что для масштабирования не очень годится, но мы решили у себя проблему тяжелых отчетов путем разведения пользователей по разным серверам.
Отказоустойчивость гораздо лучше, но… пример из жизни:) Произошел физический сбой контроллера СХД и на одном из серверов кластера SQL, базы которого на этом СХД, посыпались базы. Служба SQL этого сервера осталась зависшей, отказа по AlwaysOn не было и автоматического аварийного переключения не произошло. Все базы, у которых группа доступности с основной репликой на этом сервере, были в состоянии: на аварийном сервере — «синхронизировано», но не открыть, на резервном (рабочем) сервере — «не сихронизировано». Т.е. на основном сервере (который аварийный) базу не прочитать по причине отказа хранилища, а на резервном копии тоже не доступны. Восстановили базы из архивов, благо случилось в выходной.
Как планируете реализовать механизм проверки отставания, полностью свой или есть какие-то механизмы в MS SQL?
Согласен, что для масштабирования не очень годится, но мы решили у себя проблему тяжелых отчетов путем разведения пользователей по разным серверам.
Отказоустойчивость гораздо лучше, но… пример из жизни:) Произошел физический сбой контроллера СХД и на одном из серверов кластера SQL, базы которого на этом СХД, посыпались базы. Служба SQL этого сервера осталась зависшей, отказа по AlwaysOn не было и автоматического аварийного переключения не произошло. Все базы, у которых группа доступности с основной репликой на этом сервере, были в состоянии: на аварийном сервере — «синхронизировано», но не открыть, на резервном (рабочем) сервере — «не сихронизировано». Т.е. на основном сервере (который аварийный) базу не прочитать по причине отказа хранилища, а на резервном копии тоже не доступны. Восстановили базы из архивов, благо случилось в выходной.
В MS SQL есть что-то вроде «даты последнего обновления индекса». Но это значение на реплике не соответствует реальности, сильно отстаёт и вообще не понятно в каких случаях обновляется.
Потому я хочу попробовать сделать таблицу с одной строкой и одним столбцом. Туда с каким-то небольшим интервалом (например, 500мс) писать текущую дату. Потом приложение будет сравнивать значение в этой таблице на мастере и на реплике. Таким образом можно понять насколько по времени отстал лог транзакций на реплике. Чем меньше интервал обновления, тем меньше погрешность измерения. Нагрузки большой это создать не должно, но надо поэкспериментировать.
Потому я хочу попробовать сделать таблицу с одной строкой и одним столбцом. Туда с каким-то небольшим интервалом (например, 500мс) писать текущую дату. Потом приложение будет сравнивать значение в этой таблице на мастере и на реплике. Таким образом можно понять насколько по времени отстал лог транзакций на реплике. Чем меньше интервал обновления, тем меньше погрешность измерения. Нагрузки большой это создать не должно, но надо поэкспериментировать.
реализация полный гемор нужно поднимать домен и танцы с бубном провести еще, Вы когда нибудь в рабочее время очень быстро переключались на вторую ноду? Спасибо за статью
А как вообще без домена? А танцы там не такие уж и большие, вполне рабочее решение, но это высокая доступность, главное не думать об этом как о горизонтальном масштабировании.
У нас один раз фейловер отработал грамотно, я даже удивился. Таким хрупким все это казалось при настройке. А вот вчера кластер просто сломался при отключении одного сервера. Чтобы его поднять, пришлось применять бубен. В итоге почти час простоя.
Вот настройка зеркалирования в MS SQL 2005 — это действительно геморрой, а тут ИМХО не сложно.
В рабочее время были переключения (не аварийные, сами инициировали): нагрузка на серверах несколько повышалась, но у нас значительный запас по мощностям для нашей нагрузки, поэтому серьезных затруднений не было.
В рабочее время были переключения (не аварийные, сами инициировали): нагрузка на серверах несколько повышалась, но у нас значительный запас по мощностям для нашей нагрузки, поэтому серьезных затруднений не было.
Ну, как сказать. В зеркалировании хотя бы не был нужен домен и кластер виндовый :) Был небольшой гемор с авторизацией через сертификаты, но, в целом, мне было проще.
Если оставить за скобками настройку самого кластера и домен, то мне понравилось в AlwaysOn наличие мастеров по добавлению баз в существующую группу (ну и создание группы тоже). При большом количестве баз, существенно упрощает работу и не требует большой квалификации от админов (вполне справится специалист техподдержки:)).
Да, так себе отказоустойчивость.
Напишите о лидере СУБД, где отказоустойчивость не так себе. Будет интересно многим:)
Т.е. вы считаете, что создание двух записей в списке баз 1С у юзера — одну для мастер базы, другую для реплики — это правильно? Пользователь не должен, по-хорошему, вообще замечать процесс switchover-а, максимум — ненадолго залипнет работа.
Реализуется это, обычно, просто — через кластерный менеджер и виртуальный IP адрес для БД, к которому подключаются клиенты — им не нужно знать, что серверов два-три-много.
Реализуется это, обычно, просто — через кластерный менеджер и виртуальный IP адрес для БД, к которому подключаются клиенты — им не нужно знать, что серверов два-три-много.
Sign up to leave a comment.
Отказоустойчивость в MS SQL 2012 для 1С: Предприятие 8.2