Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Горячий резерв для БД  [new]
Ploskiy
Guest
Подскажите пожалуйста по какому пути пойти для реализации горячего бэкапа БД. В общем на MS SQL 2005 крутится БД объёмом 150 гиг, её пользуют порядка 100 юзеров и каждую неделю имеем прирост в пару гигов. От руководства поступила задача поднять горячий резерв этой БД. Методов репликации как я вижу море, но какой под такие объёмы будет самым подходящим? Спасибо.
31 авг 11, 16:13    [11207226]     Ответить | Цитировать Сообщить модератору
 Re: Горячий резерв для БД  [new]
1d0
Member

Откуда: инфа100%
Сообщений: 2521
сделай mirror
31 авг 11, 16:17    [11207270]     Ответить | Цитировать Сообщить модератору
 Re: Горячий резерв для БД  [new]
Ploskiy
Guest
А если транзакции публиковать?
31 авг 11, 16:32    [11207456]     Ответить | Цитировать Сообщить модератору
 Re: Горячий резерв для БД  [new]
1d0
Member

Откуда: инфа100%
Сообщений: 2521
Ploskiy
А если транзакции публиковать?


можно и так

всё зависит от требований
31 авг 11, 17:06    [11207804]     Ответить | Цитировать Сообщить модератору
 Re: Горячий резерв для БД  [new]
Ploskiy
Guest
Ну требование по сути одно - в случае смерти основного сервера иметь резерв, на который можно переключиться за минимальное время с минимальной потерей работы за день, а ещё лучше чтобы вообще без потерь.
1 сен 11, 07:22    [11209913]     Ответить | Цитировать Сообщить модератору
 Re: Горячий резерв для БД  [new]
Aleksey-K
Member

Откуда: Москва
Сообщений: 3116
Ploskiy
Ну требование по сути одно - в случае смерти основного сервера иметь резерв, на который можно переключиться за минимальное время с минимальной потерей работы за день, а ещё лучше чтобы вообще без потерь.

Ну если с минимальными потерями, то смотрите на кластер (но дорого!)
Database Mirroring тоже можно, но тогда для быстрого автоматического перехода на резрвный сервер (Automatic failover) с автоматическим переподключением клиентов надо:
1. Иметь третий сервер (следящий)
2. Клиент должен "уметь" переключаться на резервный сервер (Microsoft ADO.NET или SQL Native Access Client)

Можно еще попробовать и Log Shipping (перенос журнала транзакций).
Пожалуй самая дешевая технология из всех доступных High Availability для SQL Server. Да и не лишним иметь сервер для отчетов в наличии, но:
1. Для перхода на резервный сервер что-то придеться сделать ручками (не много)
2. Клиентов переподключать на новый сервер руками. Ну или что-то делать с клиентоми для автоматизации или использовать что-то типа network load balancing (NLB).

С уважением, Алексей
1 сен 11, 08:21    [11209950]     Ответить | Цитировать Сообщить модератору
 Re: Горячий резерв для БД  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31959
Ploskiy
Ну требование по сути одно - в случае смерти основного сервера иметь резерв, на который можно переключиться за минимальное время с минимальной потерей работы за день, а ещё лучше чтобы вообще без потерь.
Тогда миррор. Самое беспроблемное решение из перечисленных.

Кластер требует особого железа и повышенной квалификации, реаликация более трудоёмка в поддержке и накладывает определённые ограничения на систему, логшиппинг более трудоёмкий в настройке и обслуживании.
1 сен 11, 08:53    [11209987]     Ответить | Цитировать Сообщить модератору
 Re: Горячий резерв для БД  [new]
Shakill
Member

Откуда: мск
Сообщений: 1887
alexeyvg, а если нужно резерв реализовать, но на express выпусках, то варианта только два: самописная доставка логов либо куча триггеров (чисто теоретически) с отправкой данных на линкед сервер или ещё какие-то есть?

необходимо, чтоб после падения первого сервера, перехода работы клиентов на второй и оживления первого синхронизация начинала работать в обратную сторону.
1 сен 11, 10:55    [11210586]     Ответить | Цитировать Сообщить модератору
 Re: Горячий резерв для БД  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31959
Shakill
alexeyvg, а если нужно резерв реализовать, но на express выпусках, то варианта только два: самописная доставка логов либо куча триггеров (чисто теоретически) с отправкой данных на линкед сервер или ещё какие-то есть?

необходимо, чтоб после падения первого сервера, перехода работы клиентов на второй и оживления первого синхронизация начинала работать в обратную сторону.
Да, тогда только самописные решения.
1 сен 11, 11:21    [11210837]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить