Можно это организовать в одной локальной сети?
От клиента поступила хотелка.

Не ленись, посмотри рекламу Softpoint'а в верху страницы.

Для баз только чтение (для отчетов) да
Если же миграция в обе стороны - нужен РИБ

(1) Это не просто репликация а внешнее решение аля РИБ на прямых запросах

(2) там для отказоустойчивости. Типо если сломался сервак, на другой переезжаем

(3) а чем репликация от самого SQL не годится? какие камни?

(3) в (0) не озвучена цель.

(6) цель озвучил в (4). Для отказоустойчивости и быстрого переезда на новый сервер. Сначала хотели ночные бэкапы перекидывать, потом решили что лучше вообще онлайн синхрить.

(4) для этого есть железные решения, правда дорого...

почитай https://habr.com/ru/companies/ispsystem/articles/313066/

(5) Камень в реализации отмены транзакции. Но, т.к. вендор давно уже рекомендует бэкап делать средствами СУБД, то противопоказаний нет.

(7) да для этой цели можно использовать
то же теневое копирование но не всего сервера а только базы и не средствами системы а средствами скуля

(8) дорого не годится. клиент не богатый.

(12) нет ног - нет варенья...

SQL репликация вещь очень непростая и затратная к ресурсам,

по любому минимум 2 отдельных физических сервера нужно

(7) Тогда кластер лучше использовать. Но, Stand by - дополнительных лицензий не требует.

(12) возможно будет достаточно настроить фулл бекап + накопительный раз в 15 минут?

(15) гм, не знал что штатная репликация штука сложная. Это реально так? Чего там сложного по идее?

(15) Фулл бекап требует места, как минимум, на локальном диске  
Дабы не напрягать сервер и сеть дешевле настроить Фулл бекап, например, в 7:00, а дальше делать разностые бекапы журнала транзакций с установленной периодичностью (15 минут - это часто и большой стабильности не даст)
Но опять же есть ли место на диске для таких финтов непонятно

(12) Для небогатого клиента настрой в SQL предельное время восстановления БД, например, 15 минут (тут надо найти оптимум с использованием лога транзакций и нагрузкой записи в БД), т.е., по факту, лог транзакций будет писаться в БД принудительно и содержать данные за последние 15 минут. Если всё сломается перецепишь диски в новый комп и через 15 минут у тебя поднимется SQL в живое состояние

(16) реально
https://winitpro.ru/index.php/2020/02/13/nastrojka-replikacii-v-sql-server/

фактически там дофуя всего
https://learn.microsoft.com/ru-ru/sql/relational-databases/replication/sql-server-replication?view=sql-server-ver16

(17) проще настроить РИБ в 1С на каждые 5 минут

(16) Да. Там больше вопросы по соответствию систем и, таки, просто так не переключишься, сначала надо будет переключить БД в режим самостоятельной работы

(19) РИБ чрезмерно блокирует базу на выгрузках

(20) что, опять мелкомягкие не смогли сделать KISS?

(19) или тупо забацать заливку в "спящую" БД

(21) репликация думаешь не блокирует???

(22) не мелкомягкие а один непризнанный геня

почитай уже про отказоустойчивый кластер

Если вторая база будет "холодная", то можно просто каждые 5 минут делать бэкап-восстановление журнала транзакций из рабочей базы. И раз в сутки - полный бэкап-восстановление.

(24) ну бэкап не блокирует, например, насколько я понимаю

(28) мдя

Геня ты бы изучил уже теорию/матчасть
Ну там устройство СУБД типа https://infostart.ru/1c/articles/709159/

и подумал чем бэкап отличается от репликации (с кучей условий)

(27) да, похоже так будет норм.

(30) чтобы я учил эту матчасть клиенту не по бюджету будет. Думаю с бэкапами норм.

(12) Если клиент не богатый - то самый "дешевый" для него вариант это второй сервер в кладовке - если первый сдох аппаратно, то носители с системой и базой подкинули на запасной и вперед - все остальные решения сильно дороже.
З.Ы.: Лицензию на сервер приложений привязать на однопользовательский HASP, а не на железо.

(33) блин ну в постгресе есть такая штука. На slave перекидываются завершенные транзакции и порядке их старта.

Переключить slave в режим мастера и изменить в ИБ путь до базы или поменять dns запись. Делов на 2 минуты.

Просто, надёжно, легко мониторить, в 100500 раз лучше бекапа раз в 5минут. Бесплатно.

В MS SQL тоже должно быть что-то такое.

(34) На сколько мне известно, транзакция постргри и ms SQL различаются достаточно сильно
Чисто по логике: обвалилась основная БД - в каком состоянии slave? что в неё попало, что нет? То, что сломало основной сервер попало в реплику или нет (тупо злобный хакер отправил запрос модификации данных или шифровальщик добрался до БД)? И, таки, ресурсы на передачу данных транзакции к подчинённому серверу имеют место тратиться

Так, что однозначного ответа на вопрос "Что лучше?" нет.
Всё имеет свои ограничения применимости, даже отказоустойчивый кластер (кроме стоимости имеет лаг актуальности данных)

В своё время была популярна такая штука как реплика портов - т.е. пакеты, например, ТСР приехавшие на Порт1 коммутатора, дублировались в Порт2. По факту, ставим 2 физически разнесённых машины с одинаковым софтом и настраиваем их одновременную работу, если основная погнулась, то в работу переключаем из Порта2 (физически выдернули в серверной кабель и воткнули в Порт1 - вообще, секунды на переключение с 0 требованием к квалификации исполнителя) Но такое решение тоже имеет свои подводные камни (как-то тихо и мирно потухла сия идея)

(35) на случай краха основной бд и невозможности его поднять, попадет туда явно больше чем в бекап 5минутной давности.

Нагрузка на мастер минимальна, можно пренебречь. Со слейва даже бекапы полные снимают, чтобы мастер не грузить.

Но вообще да. Это не отказоустойчивость в строгом понимании слова.

(35) И в чём различие транзакций? ACID - он и в Африке ACID

(35) "То, что сломало основной сервер попало в реплику или нет (тупо злобный хакер отправил запрос модификации данных или шифровальщик добрался до БД)?"

А от этого спасает point in time recovery.

Восстанавливаешь бд на состояние за 1с до сбоя.

(37) fedor, очевидно, перепутал транзакции с репликаций.

Репликация там правда по разному устроена. Но, имхо, master-slave должен +- одни и те же задачи решать.

(38) Осталось выяснить точное время сбоя, а отнять от него секунду - нефиг делать...

Как бы,физический отказ сервера и неправильные данные в нем - это совершенно разные проблемы,и решения у них тоже разные.

(33) А 1с еще выпускает аппаратные ключи, кстати? У клиента еще "железные"

(41) Если данные уконтропупили любым способом (RAID в зеркале рассыпался, сервер сгорел, порушили БД битые сектора диска, пользователи/хакеры постарались или шифровальщик поработал), самый распространённый вариант, хоть как-то, их вернуть в приемлемое состояние - восстановление из бекапа (очень желательно - свежего).
В остальном - частности, кому-то критична потеря 15 минут работы (нужны одни меры и надёжность системы, в т.ч. и аппаратные), кому-то и сутки не проблема (меры обеспечения надёжности хранения данных совсем другие)

Кроме лага допустимой потери информации, есть параметр "Скорость восстановления работоспособности" - да поломались, откатываемся к версии данных, например, 1 час назад, но за 10 минут - т.е. система гарантированно работает дальше (возможно, с какими-то ограничениями) имея дырку в данных, максимум, в 1 час и восстановление оного может растянуться, например, на 5-6 часов (тупо, садим несколько операторов которые будут набивать данные за потерянный час, а лучше 15 минут). Называется: пока летим на одном крыле, но, таки, летим

Посему, суть одна и та же - заранее предусмотреть меры по надёжной работе системы и выработка параметров и методов  её быстрого восстановления (резерв мощности оборудования, настройка копирования, применение СХД, разделение хранения старых и новых данных в разных местах для минимизации потерь и объема копий и т.д. и т.п.)
Сии мероприятия стоят денег и требуют квалификации (как минимум, для их правильной организации)

(42) Давно бы перешли на использование сертификата на рутокене (с неизвлекаемым ключом, версии 2.0 или 3.0) вместо морально устаревшего хаспа. Это бы сочетало в себе плюсы и аппаратной и программной лицензии. И ключ был бы именным, и независимость от железа бы присутствовала.

(43) pitr и master-slave репликация в постгресе это дёшево, не требует большой квалификации (одна глава руководства на русском + пару скриптов) и не требует особого админства. Просто работает.

Нет ни одной причины её не использовать.

P.S. Неужели в ms sql не так? Может просто форум не профильный?

(45) когда в SQL простая и дефолтная база, то репликации это просто.

а вот например у базы нестандатное смещение дат, или например тригер который пишет в другую базу, или уровень изоляции нестандартный и начинаются танцы с бубном.

а если еще на мастере что-то произойдет и перейдешь на слейв, то вернутся обратно на мастер это целый квест.

Короче репликации ни разу не заменяют кластер...

(0) тут почитай https://ittraveler.org/ustanovka-i-nastrojka-alwayson-na-ms-sql-2016/

(45) Когда я рылся в этой теме (давно дело было)
первое на что обратил внимание в случае репликации: если в мастере ломаются данные, то через период обмена они гнутся и в слэйве, а когда сие обнаружится - неизвестно, через день или через 5 (погнулись, например, кассовые ордера, а всё остальное целое и ломаться начнёт позднее)
А так, не велика проблема настроить репликацию и в MS

Схема репликации данных, до некоторой степени, спасает при глухом выходе из строя мастера. И то, может быть период, когда в слэйв летят битые данные (медленная деградация диска) и установить степень достоверности информации в БД на вскидку не получится

(46) так и кластер не панацея, там свои подводные камни есть. Нужен комплекс мероприятий для устойчивости системы

(48) Вообще, в sql сервере есть такая штука как automatic page repair, когда повреждённые на мастере страницы восстанавливаются за счёт реплики. Не без оговорок, но тем не менее.

(27) "И раз в сутки - полный бэкап-восстановление." - это лишнее, если постоянно подливать журнал в копию.
А если раз сутки восстанавливать, достаточно просто иметь в наличии копии журнала транзакций, которые делать каждые 5 минут. И тогда их можно не восстанавливать. Использовать только при сбоях или расследовании индицентов.

У нас террабайтные копии рабочих баз живут в режиме "подливания логов" каждые 5 минут. Ежедневно восстанавливать из бэкапа такое не будешь.

работает

(51) Это хорошо конечно, но в случае, если вдруг придется включить копию в онлайн по какой-то причине, то после этого уже не получится "подливать логи". И чтобы восстановить копию, придется заново плясать от полного бэкапа со всей цепочкой. Так что, лучше чтобы он всё-таки был хотя бы раз в сутки. Пусть даже и не восстанавливался в копию.

(51) репликация не заменяет бекапы. Это средство отказоустойчивости и/или распределения нагрузки (но не в случае с 1С)

В (54) ответ (53)