S>Для AlwaysON AG есть мысль вывести все обработки 1С не меняющие данные на read-only ноду. Проблема в том, что 1С не сможет задействовать базу только для чтения напрямую (только через COM-объект), есть ли какой-нибудь способ уговорить её?
А средствами 1с смотрели? Кажется что-то видел с теме "отказоустойчивый кластер 1с 8.3"

У нас админы делали на 8.2 (насколько я помню)
1. логшиппинг каждые 10 минут (для восстановления базы в случае сбоя основного сервера скуля, согласно SLA, прости Господи)
2. Зеркалирование средствами скуля (mirroring). В этом случае база работает нормально, но из нее не должно быть никаких попыток записи — это обеспечили программисты 1с некоторым допиливанием. Зеркала используются для формирования отчетности (для разгрузки основной базы)

S>Для AlwaysON AG есть мысль вывести все обработки 1С не меняющие данные на read-only ноду. Проблема в том, что 1С не сможет задействовать базу только для чтения напрямую (только через COM-объект), есть ли какой-нибудь способ уговорить её?
А средствами 1с смотрели? Кажется что-то видел с теме "отказоустойчивый кластер 1с 8.3"

У нас админы делали на 8.2 (насколько я помню)
1. логшиппинг каждые 10 минут (для восстановления базы в случае сбоя основного сервера скуля, согласно SLA, прости Господи)
2. Зеркалирование средствами скуля (mirroring). В этом случае база работает нормально, но из нее не должно быть никаких попыток записи — это обеспечили программисты 1с некоторым допиливанием. Зеркала используются для формирования отчетности (для разгрузки основной базы)

P.S. уточнил у админа — он сказал, что в restoring действительно база не работает. Поэтому они делают snapshot с зеркала и уже на нем работают на чтение.