Ну, как сказать. В зеркалировании хотя бы не был нужен домен и кластер виндовый :) Был небольшой гемор с авторизацией через сертификаты, но, в целом, мне было проще.
У нас один раз фейловер отработал грамотно, я даже удивился. Таким хрупким все это казалось при настройке. А вот вчера кластер просто сломался при отключении одного сервера. Чтобы его поднять, пришлось применять бубен. В итоге почти час простоя.
Синхронная. Печаль заключается в том, что таки отстают. stackoverflow.com/questions/21161085/sql-server-2012-alwayson-synchronous-replica-is-not-actually-synchronous-for-rea
Кроме того, синхронная плохо подходит в случаях, когда много записей, а машина реплики пишет медленней, чем машина мастера. Тогда при пиковых нагрузках начинает тормозить запись в мастер.
Для нашего проекта я хочу сделать в конечном итоге асинхронную реплику, а также механизм для проверки отставания, чтобы при его росте переставать направлять запросы на реплику.
А вообще, всё это не очень годится для масштабирования. Для отказоустойчивости — да, а при постоянном росте нагрузки и объема данных придётся таки прийти к шардингу. Хотя, многое зависит от проекта…
Используем AlwaysOn на проекте в режиме Primary — Readable Secondary
Поскольку реплики могут «отставать» в синхронизации, нельзя бездумно отправлять туда все запросы на чтение. Пришлось в приложении самим определять «безопасные» места, в которых можно использовать неактуальные данные. В этих местах запросы на чтение могут идти на реплику.
Самое интересное в данной задаче то, что нельзя просто так взять и построить индекс для быстрой выборки по двум столбцам, которые являются границами диапазона.
Если мы делаем индекс по (begin_ip, end_ip), то при запросе BETWEEN сперва поиском по дереву индекса найдется первая строка, у которой begin_ip >= LONG_IP_ADDRESS. А затем начнется последовательное сканирование всех последующих строк с проверкой end_ip <= LONG_IP_ADDRESS. И это медленно.
Вероятность, что опасение сбудется, стремится к единице. Потому надо либо переходить на российские сервисы, либо самим переноситься из России. Кому что ближе и проще.
Я бы еще рассмотрел вариант сокрытия/подмены истинного места проживания от западных компаний, чтобы не попасть под раздачу. Но этот вариант не везде сработает, да и не спасёт от особо грубых мер вроде бана российских адресов.
Разделяю мнение, что категорично неприязненное отношение к цензуре свойственно крайне узкой категории людей, хотя среди аудитории хабра таких людей много.
Я не могу точно сказать как выгоднее поступить гитхабу в данной ситуации, потому что мне неизвестно их положение на российском рынке. Вполне может быть, что репутационные потери гитхаба, как надёжного сервиса для законопослушных людей покажутся его руководству более весомыми, чем потери аудитории, предпочитающей размещать незаконный контент, и человекочасы, необходимые для реализации функций блокировки.
Когда мы узнаем о решении гитхаба, можно будет делать какие-то выводы.
Кроме того, синхронная плохо подходит в случаях, когда много записей, а машина реплики пишет медленней, чем машина мастера. Тогда при пиковых нагрузках начинает тормозить запись в мастер.
Для нашего проекта я хочу сделать в конечном итоге асинхронную реплику, а также механизм для проверки отставания, чтобы при его росте переставать направлять запросы на реплику.
А вообще, всё это не очень годится для масштабирования. Для отказоустойчивости — да, а при постоянном росте нагрузки и объема данных придётся таки прийти к шардингу. Хотя, многое зависит от проекта…
Поскольку реплики могут «отставать» в синхронизации, нельзя бездумно отправлять туда все запросы на чтение. Пришлось в приложении самим определять «безопасные» места, в которых можно использовать неактуальные данные. В этих местах запросы на чтение могут идти на реплику.
Если мы делаем индекс по (begin_ip, end_ip), то при запросе BETWEEN сперва поиском по дереву индекса найдется первая строка, у которой begin_ip >= LONG_IP_ADDRESS. А затем начнется последовательное сканирование всех последующих строк с проверкой end_ip <= LONG_IP_ADDRESS. И это медленно.
Насколько я знаю, достаточно одного вопроса, поведение будет аналогичным:
var location = vendor?.ContactPerson.HomeAddress.LineOne;
Я бы еще рассмотрел вариант сокрытия/подмены истинного места проживания от западных компаний, чтобы не попасть под раздачу. Но этот вариант не везде сработает, да и не спасёт от особо грубых мер вроде бана российских адресов.
Я не могу точно сказать как выгоднее поступить гитхабу в данной ситуации, потому что мне неизвестно их положение на российском рынке. Вполне может быть, что репутационные потери гитхаба, как надёжного сервиса для законопослушных людей покажутся его руководству более весомыми, чем потери аудитории, предпочитающей размещать незаконный контент, и человекочасы, необходимые для реализации функций блокировки.
Когда мы узнаем о решении гитхаба, можно будет делать какие-то выводы.