Резервная База-клон

[Tomash]

Здравствуйте!

база 7.7 MSSQL терминальный сервер

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

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

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


- в идеале, работа на двух серверах одновременно - любой документ дублируется, в любой момент при падении основного сервера, можно продолжить работу на резервном, а когда основной поднимется - привести их в соответствие.

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

реализация второго варианта вроде бы не вызывает особых трудностей, кроме способа передать/перенести 20+ гигабайт за короткий срок и в автоматическом режиме, но, в принципе, хороший канал интернета в обоих зданиях этот вопрос решает.

а вот реально ли реализовать "идеальный вариант" ?
слышал, что-то подобное можно сделать в 8-ке настройкой кластера

а в 7-ке ?

приветствуется любой личный опыт решения хотя бы отдаленно похожих задач

 

[Glukman]

Если заморочитесь, то теоретически возможно 1.) средствами sql. 2.) Поднять УРИБ
При SQL возникают вопросы согласованности данных.
1. Файловая часть должна быть идентична.
2. Скорость канала связи должна быть достаточной для зеркалирования sql базы.
3. Возникает вопрос обратного согласования после восстановления центрального сервера.

Вопросы общие и для SQL и для УРБД:
1. что будете считать сбоем для включения резервного сервера. и дальше реализация прозрачного механизма переключения для пользователя?


ЗЫ: а почему изначально сервер не вынести в другое здание?
ЗЗЫ: в восьмерке ваша задача посредством ввода кластера не решается, можете более доступно ознакомится с принципом работы по ссылке:

Ссылка скрыта от гостей

 

[Tomash]

Если заморочитесь, то теоретически возможно средствами sql.
Возникают вопросы согласованности данных.
1. Файловая часть должна быть идентична.
2. Скорость канала связи должна быть достаточной для зеркалирования sql базы.

зеркалирование sql в режиме реального времени ? или вы имеете в виду, ежедневное зеркалирование ночью?

ЗЫ: а почему изначально сервер не вынести в другое здание?

другое - это склад, там тоже не все "слава богу", и держать там основной сервер даже ещё более рискованно. задумка в том, что 2 ненадёжных здания всё-таки лучше чем 1 ненадёжное, они на разных подстанциях, вероятность что в обоих одновременно отключат свет - крайне мала.

 

[Glukman]

"зеркалирование sql в режиме реального времени ? " - именно

 

[Tomash]

"зеркалирование sql в режиме реального времени ? " - именно

я понимаю, что вы задали направление, и мне необходимо его изучить, и я это конечно сделаю, но может у вас есть время немного развернуть ответ:

- файловая часть должна быть идентична - вы имеете в виду саму папку с базой данных, настройки пользователей, конфигуратора и проч ? или что-то ещё?

- скорость соединения вряд ли станет камнем преткновения, если остальные проблемы будут решены, 100/100 мбит реально дотянуть до обоих зданий.

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

- выявление сбоя - предварительно вручную, не заметить его невозможно, телефон разорвётся моментально от звонков возмущенных пользователей

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


ну и сам процесс зеркалирования, вы имеете в виду стандартное зеркалирование на другой диск, но с указанием вместо диска удалённого компьютера, или есть тонкости?

простите если мучаю, но необходимо достаточно быстро составить мнение о целесообразности и объеме работ

 

[Glukman]

- файловая часть должна быть идентична - вы имеете в виду саму папку с базой данных, настройки пользователей, конфигуратора и проч ? или что-то ещё? - именно так
- с обратным согласованием примерно так и есть, должны учесть что доступ к резервной или рабочей БД должен отключаться.
сам процесс зеркалирования - средствами sql - на другой сервер sql.

ИМХО: в вашем случае мне кажется проще будет развернуть УРБД.
и обмен каждые 5 минут.
т.е. получается что вы в первом здании делаете центральную БД во втором переферийную
правила миграции настраиваете везде место создания и центр.
из тонкостей - при обновлении нужно обязательно делать монопольную выгрузку из ЦБ в ПБ
разграничить доступ к БД - что бы не по вбивали одновременно объектов.

в случае УРБД вы решаете свою задачу фактически штатными средствами, ну и с данными относительно порядок получается.

+ инф. по тому что такое УРБД и как оно работает

Ссылка скрыта от гостей

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

 

[Tomash]

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

да ничего особо масштабного, бэкап средствами sql ~ 30 гб, пользователей ~ 30, одновременно 20-25.

спасибо большое за помощь, sql - зеркалирование звучит достаточно понятно и надёжно, УРБД не сталкивался, буду изучать, но наверное откажусь в пользу sql

 

[MisterSpock]

Не так давно столкнулся со схожей задачей, правда, в контексте mysql, в итоге, довольно сильно помог вот этот материальчик про

Ссылка скрыта от гостей

, может, кому еще пригодится. На удивление доходчиво написано.