Сообщение Re[6]: Работа с log shipping в SQL Server от 23.10.2014 6:49
Изменено 23.10.2014 6:55 igor_ku
Здравствуйте,
Just thoughts aloud...
А что если так:
1 — делаем репликацию. Т.е. имеем всегда online актуальную копию БД на другом сервере, на котором её (БД) можно портить.
2 — перед тем как начать портить реплицируемую БД делаем следующее:
2а — останавливаем репликацию
2б — делаем снэпшот реплицируемой БД
3 — портим БД, fun&profit, etc.
4 — после окончания порчи:
4а — ресторим реплицируемую БД из снэпшота (это не должно занять много времени и зависит только от кол-ва измененных данных во время порчи)
4б — восстанавливаем репликацию
Там выше писали, что с репликацией якобы есть проблемы. Ну не знаю, не знаю, у нас на прод-серверах работает без проблем, технология стара как мир и лично по моим ощущениям, самая надежная. Не думаю, что с неким кастомным решением синхронизации данных будет меньше проблем, полагаю раз в 10-100 больше.
Я сам делать так, как я написал выше, не пробовал, так что критика приветствуется.
Just thoughts aloud...
А что если так:
1 — делаем репликацию. Т.е. имеем всегда online актуальную копию БД на другом сервере, на котором её (БД) можно портить.
2 — перед тем как начать портить реплицируемую БД делаем следующее:
2а — останавливаем репликацию
2б — делаем снэпшот реплицируемой БД
3 — портим БД, fun&profit, etc.
4 — после окончания порчи:
4а — ресторим реплицируемую БД из снэпшота (это не должно занять много времени и зависит только от кол-ва измененных данных во время порчи)
4б — восстанавливаем репликацию
Там выше писали, что с репликацией якобы есть проблемы. Ну не знаю, не знаю, у нас на прод-серверах работает без проблем, технология стара как мир и лично по моим ощущениям, самая надежная. Не думаю, что с неким кастомным решением синхронизации данных будет меньше проблем, полагаю раз в 10-100 больше.
Я сам делать так, как я написал выше, не пробовал, так что критика приветствуется.
Re[6]: Работа с log shipping в SQL Server
Здравствуйте,
Just thoughts aloud...
А что если так:
1 — делаем репликацию. Т.е. имеем всегда online актуальную копию БД на другом сервере, на котором её (БД) можно портить.
2 — перед тем как начать портить реплицируемую БД делаем следующее:
2а — останавливаем репликацию
2б — делаем снэпшот реплицируемой БД
3 — портим реплицируемую БД, fun&profit, etc.
4 — после окончания порчи:
4а — ресторим реплицируемую БД из снэпшота (это не должно занять много времени и зависит только от кол-ва измененных данных во время порчи)
4б — восстанавливаем репликацию
Там выше писали, что с репликацией якобы есть проблемы. Ну не знаю, не знаю, у нас на прод-серверах работает без проблем, технология стара как мир и лично по моим ощущениям, самая надежная. Не думаю, что с неким кастомным решением синхронизации данных будет меньше проблем, полагаю раз в 10-100 больше.
Я сам делать так, как я написал выше, не пробовал, так что критика приветствуется.
Just thoughts aloud...
А что если так:
1 — делаем репликацию. Т.е. имеем всегда online актуальную копию БД на другом сервере, на котором её (БД) можно портить.
2 — перед тем как начать портить реплицируемую БД делаем следующее:
2а — останавливаем репликацию
2б — делаем снэпшот реплицируемой БД
3 — портим реплицируемую БД, fun&profit, etc.
4 — после окончания порчи:
4а — ресторим реплицируемую БД из снэпшота (это не должно занять много времени и зависит только от кол-ва измененных данных во время порчи)
4б — восстанавливаем репликацию
Там выше писали, что с репликацией якобы есть проблемы. Ну не знаю, не знаю, у нас на прод-серверах работает без проблем, технология стара как мир и лично по моим ощущениям, самая надежная. Не думаю, что с неким кастомным решением синхронизации данных будет меньше проблем, полагаю раз в 10-100 больше.
Я сам делать так, как я написал выше, не пробовал, так что критика приветствуется.