Здравствуйте, Somescout, Вы писали:
S>Пытаюсь разобраться в вариантах настройки отказоустойчивого SQL Server. Правильно ли я понимаю, что сейчас нельзя настроить его так, чтобы клиентские сессии не прерывались во время Failover'а? S>skipped
Я не очень хорошо разбираюсь в этой теме, но судя по списку вопросов, вам поможет только DB2. Там уж точно есть непрерывная работа и не-падающие соединения.
Пытаюсь разобраться в вариантах настройки отказоустойчивого SQL Server. Правильно ли я понимаю, что сейчас нельзя настроить его так, чтобы клиентские сессии не прерывались во время Failover'а?
Можете что-нибудь подсказать по текущим вариантам кластеризации (кластеризация VM, кластеризация SQL, Mirroring, AlwaysOn AG) — на что лучше смотреть?
Можно ли в варианте AlwaysOn AG разместить базу на общем хранилище и работать с одной копией базы? (Вопрос глупый, но вдруг) Или это возможно только в варианте с кластером SQL (и VM)?
Можно ли в версии ранее 2016 для AlwaysOn Group настроить Server Link к read-only ноде (т.е. чтобы можно было сделать вьюшку, всегда ссылающуюся на read-only ноду)?
Нормально ли что в AlwaysOn AG на Secondary ноде все остальные сервера помечены как unknown state? (Гугление показало что да, но...)
Нормально ли что в асинхронном режиме для AlwaysOn AG диалог Failover всегда показывает предупреждение о Data Loss (в синхронном режиме всё в порядке)?
Для AlwaysON AG есть мысль вывести все обработки 1С не меняющие данные на read-only ноду. Проблема в том, что 1С не сможет задействовать базу только для чтения напрямую (только через COM-объект), есть ли какой-нибудь способ уговорить её? Пока единственное что приходит в голову — отдельная база с вьюшками, ссылающимися на таблицы данных в read-only реплике + локальные таблицы для изменяемых данных. Делал так для другой задачи — всё работает отлично, но может есть более правильный вариант?
Здравствуйте, Слава, Вы писали:
С>Здравствуйте, Somescout, Вы писали:
S>>Пытаюсь разобраться в вариантах настройки отказоустойчивого SQL Server. Правильно ли я понимаю, что сейчас нельзя настроить его так, чтобы клиентские сессии не прерывались во время Failover'а? S>>skipped
С>Я не очень хорошо разбираюсь в этой теме, но судя по списку вопросов, вам поможет только DB2. Там уж точно есть непрерывная работа и не-падающие соединения.
1) Вопрос не зря по SQL Server, ответы хотелось бы получить именно по нему.
2) Мне непрерывные соединения не сильно важны на самом деле (задачи не настолько критичные, особенно в случае аппаратного сбоя сервера), интересно именно есть ли они в принципе.
S>Для AlwaysON AG есть мысль вывести все обработки 1С не меняющие данные на read-only ноду. Проблема в том, что 1С не сможет задействовать базу только для чтения напрямую (только через COM-объект), есть ли какой-нибудь способ уговорить её?
А средствами 1с смотрели? Кажется что-то видел с теме "отказоустойчивый кластер 1с 8.3"
У нас админы делали на 8.2 (насколько я помню)
1. логшиппинг каждые 10 минут (для восстановления базы в случае сбоя основного сервера скуля, согласно SLA, прости Господи)
2. Зеркалирование средствами скуля (mirroring). В этом случае база работает нормально, но из нее не должно быть никаких попыток записи — это обеспечили программисты 1с некоторым допиливанием. Зеркала используются для формирования отчетности (для разгрузки основной базы)
P.S. уточнил у админа — он сказал, что в restoring действительно база не работает. Поэтому они делают snapshot с зеркала и уже на нем работают на чтение.
Здравствуйте, Somescout, Вы писали:
S>Можно ли в версии ранее 2016 для AlwaysOn Group настроить Server Link к read-only ноде (т.е. чтобы можно было сделать вьюшку, всегда ссылающуюся на read-only ноду)?
Не совсем. Там строка соединения используется, что 1С не поддерживает (точнее, не поддерживала лет 5-6 назад,
что там сейчас — фиг его знает).
S>Нормально ли что в AlwaysOn AG на Secondary ноде все остальные сервера помечены как unknown state? (Гугление показало что да, но...) S>Нормально ли что в асинхронном режиме для AlwaysOn AG диалог Failover всегда показывает предупреждение о Data Loss (в синхронном режиме всё в порядке)?
ЕМНИП, да. Не вижу в этом ничего странного, по крайней мере.
S>Для AlwaysON AG есть мысль вывести все обработки 1С не меняющие данные на read-only ноду. Проблема в том, что 1С не сможет задействовать базу только для чтения напрямую (только через COM-объект), есть ли какой-нибудь способ уговорить её?
Мы в своё время использовали для read-only запросов от 1С зеркалирование и создание поверх зеркала снапшота.
Всё работало нормально.
