Кластер?

KGP

Задача такова:есть 4 (взаимосвязанные) базы данных MS SQL Server 2000, необходимо ...настроить общий backup (не путать с backup-ом базы данных), то есть административными и/или железячными решениями иметь возможность восстановить все базы данных к некоторому моменту.1) разнести их по разным серверам и из используя ежечасный full-mode backup откатывать к одной и той же точке (приблизительно) при падении любой из них.2) использовать родной кластер MS SQL Server3) другие варианты (смесь решений), которые вами уже использовались.Заранее спасибо.на что не влияю к тому безразличен.
16 ответов

KGP

log shipping or snapshot replication will be enough


KGP

Взаимосвязанные? Это через репликацию, DTS, системы уведомлений и как еще?


KGP

купить один большой сервак и положить все четыре базы на него. Умрет - так умрет все и никаких проблем с синхронизацией 8)Шутка-шуткой, но в ряде простых случев сработает.А если не устраивает, надо контрольные точки синхронно ставить, и от постановки первой до завершения 4-й все операции запрещать


KGP

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


KGP

Я очень советую почитать в БОЛ про резервное копирование при тразнакционной репликации. Надеюсь, там найдете ответы.


KGP

Я очень советую почитать в БОЛ про резервное копирование при тразнакционной репликации. Надеюсь, там найдете ответы.
Интересно, а кто-нибудь имеет опыт подобного резервного копирования и востановления?


KGP

Я очень советую почитать в БОЛ про резервное копирование при тразнакционной репликации. Надеюсь, там найдете ответы.
пока, кроме кластеризации другого метода синхронного backup нескольких баз данных не вижу.


KGP

пока, кроме кластеризации другого метода синхронного backup нескольких баз данных не вижу.
А я и на кластере вот не вижу. Поясните свою задумку как средствами кластера добиться того, чего нельзя добиться простым некластерным сервером.Например, именованые транзакции. Named Log MarksSQL Server 2000 introduces the concept of named transactions. Named log marks allow a transaction log backup to be restored up to a particular named transaction. This further enhances the point-in-time restore functionality on the transaction log backups.Вообще советую на всякие хитрые способы полагаться, но все же заранее свою процедурку межсерверной сверки целостности данных уже сейчас написать, так спокойней.


KGP

А если попробовать перевести Ваши 4 базы (на одном сервере) в режим DboUseOnly и друг за дружкой их отбекапить? Пусть не сихронно, но никаких изменений пользователи за это время сделать не смогут.Т.е. отправная точка есть.Теперь восстановление логов. Можно запускать синхронно с помощью 4-х джобов. А можно и не синхронно.Если все операции с разными БД были обернуты в транзакцию, то она подтвердится во всех БД в одно и тоже время. Т.е. если Вы будете восстанавливать ваши БД на тот момент времени, когда с БД1 работа уже завершилась, а с БД3 еще не начиналась (естественно все это внутри одной транзакции), то Вы получите ваши БД на момент открытия Вашей транзакции.
пока, кроме кластеризации другого метода синхронного backup нескольких баз данных не вижу.
А можете рассказать, как Вы делаете синхронный бекаб нескольких БД в случае использования кластера?
Вообще советую на всякие хитрые способы полагаться, но все же заранее свою процедурку межсерверной сверки целостности данных уже сейчас написать, так спокойней.
Обеими руками за!!!


KGP

1) А если попробовать перевести Ваши 4 базы (на одном сервере) в режим DboUseOnly и друг за дружкой их отбекапить? 2) Если все операции с разными БД были обернуты в транзакцию, то она подтвердится во всех БД в одно и тоже время.
1) просто backup баз данных делаем через middleware (центральной ASP стоп и вперед)2) надо смотреть исходники, чтоб в общей транзакции не только взаимосвязанные, но и полные логические цепочки остались. 3) кластером - не backup, а пытатся гарантию отказоустойчивости навести


KGP

1) просто backup баз данных делаем через middleware (центральной ASP стоп и вперед)2) надо смотреть исходники, чтоб в общей транзакции не только взаимосвязанные, но и полные логические цепочки остались. 3) кластером - не backup, а пытатся гарантию отказоустойчивости навести
1. Backup может продолжаться несколько минут. И что, в течении этих минут Ваш сайт будет недоступен??? Плохо.2. Надо не только смотреть, но и исправить их. Чтобы ВСЕ группы операций осуществлялись внутри транзакции. А если для связи БД у Вас применяется репликация, то полностью поддерживаю Crimean'a: Прочитайте в БОЛ про резервное копирование при тразнакционной репликации. 3. И какую отказоустойчивость вы хотите получить? Для минимизации проблем с жесткими дисками применяют RAID массивы. Это именно то, что Вам и нужно.


KGP

А вообще я перевел бы вопрос в другую совсем плоскость: а зачем Вам 4 связанных сервера БД? Если из-за производительности, и они выполняют примерно то же самое, то я бы потратил немного денег и слил бы все в один сервер, но мощный - никаких проблем с интерфейсами и из рассинхронизацией.Если это разные филиалы географически разнесенные - то тоже свел бы все в одну БД, оставив локальные серверы приложений.Если это сугубо разные системы, участвующие в каком-то одном бизнес процессе - опять таки, какие препятствия собрать все четыре БД под крышей одного сервера, а лучше прямо в одну базу? Тогда хоть на общее системное время можно полагаться и восстанавливать по STOPAT.Иначе адача Ваша, без поддержки прикладными методами, административного/железячного решения не имеет.Точнее имеет, но с очень суровым ограничением. Называется это - оффлайновый бэкап, суть которого уже была озвучена уважаемым Александром Спелициным. Раз в определенный момент времени прикладухи останавливаются, пользователи выгоняются, делается бэкап на всех связанных серверах, и потом снова все запускается. Только этот метод дает гарантию целостности, если нельзя изменять логику работы приложений.Как правило, это наталкивается на дилему: чаще останавливать систему или смириться с потерей большего объема работы "если что".


KGP

А вообще я перевел бы вопрос в другую совсем плоскость: а зачем Вам 4 связанных сервера БД?
Изначально говорилось только про 4 связанные БД, про разные сервера не было ни слова. 2 KGP:Вот скрипт. Обратите внимание, на то, что время в команде восстановления журнала должно быть результатом выполнения 2-го getdate():
set nocount on
create database d1
create database d2
go

use d1
go
create table t1 (id int)
go

use d2
go
create table t2 (id int)
go

use master
go

backup database [d1] TO DISK = N'D:\Backup\d1.dat' WITH INIT, NOUNLOAD, NAME = N'D1 backup', NOSKIP, STATS = <b>10</b>, NOFORMAT 
backup database [d2] TO DISK = N'D:\Backup\d2.dat' WITH INIT, NOUNLOAD, NAME = N'D2 backup', NOSKIP, STATS = <b>10</b>, NOFORMAT 
go

use d1
go
insert t1 (id)
Select <b>1</b>
union
Select <b>2</b>
union
Select <b>3</b>

insert d2..t2 (id)
Select <b>1</b>
union
Select <b>2</b>
union
Select <b>3</b>
go

begin tran
 insert d2..t2 (id)
 Select <b>4</b>
 union
 Select <b>5</b>

Select * from t1
Select * from d2..t2

 Select getdate() 

-- ждем 30 сек.
 WAITFOR DELAY '00:00:30'

--Запоминаем дату/время вызвав getdate(). Именно это значение использовать при восстановлении журналов. 
 Select getdate() 

 insert d1..t1 (id)
 Select <b>6</b>
 union
 Select <b>7</b>
commit tran

 insert d1..t1 (id)
 Select <b>61</b>
 union
 Select <b>71</b>

BACKUP LOG d1 to DISK = N'D:\Backup\d1_log.dat' WITH INIT, NOUNLOAD, NAME = N'D1 Log backup', NOSKIP, STATS = <b>10</b>, NOFORMAT 
BACKUP LOG d2 to DISK = N'D:\Backup\d2_log.dat' WITH INIT, NOUNLOAD, NAME = N'D2 Log backup', NOSKIP, STATS = <b>10</b>, NOFORMAT 

use master
go

-- восстанавливаем базы
RESTORE DATABASE d1 FROM DISK = N'D:\Backup\d1.dat' WITH NORECOVERY
RESTORE DATABASE d2 FROM DISK = N'D:\Backup\d2.dat' WITH NORECOVERY

-- восстанавливаем журналы, на момент времени, запомненный в предыдущей транзакции (у Вас это время будет дгугим :-) ) 
RESTORE LOG d1 FROM DISK = N'D:\Backup\d1_log.dat' WITH RECOVERY, stopat = '20051212 11:46:25 Время изменить!!!'
RESTORE LOG d2 FROM DISK = N'D:\Backup\d2_log.dat' WITH RECOVERY, stopat = '20051212 11:46:25 Время изменить!!!'
go

Select * from d1..t1
select * from d2..t2
go

drop database d1
drop database d2
go


set nocount off
Выполните их и убедитесь, что в обоих таблицах данные которые были только до момента старта транзакции.


KGP

Изначально говорилось только про 4 связанные БД, про разные сервера не было ни слова.
А, ну извините, перемудрил. Раз все на одном сервере, так делать обычный RESTORE ... WITH STOPAT= да и всех делов.


KGP

Вот скрипт. Обратите внимание, на то, что время в команде восстановления журнала должно быть результатом выполнения 2-го getdate():
Респект за идею обертку сущностных изменений в распределенную транзакцию.
1) Если это сугубо разные системы, участвующие в каком-то одном бизнес процессе - опять таки, какие препятствия собрать все четыре БД под крышей одного сервера, а лучше прямо в одну базу? 2) Раз в определенный момент времени прикладухи останавливаются, пользователи выгоняются, делается бэкап на всех связанных серверах, и потом снова все запускается.
1) есть ЯДРО и остальные ндцать баз данных ... сливать в одну базу данных - не выход, и не вход2) пользователи НЕ выгоняются, просто есть общее место, которое допускает 'распределенные' операции изменения данных или нет(в ASP - COM-Singleton - который выдает страничку 'ожидания' с редиректом), а выборки и т.п. без проблемPS:Для себя сделал вывод:кластер на 2 компа (RAID 5-го уровня).backup еженедельный разностный с приостановом OR backup разностный (каждый час при idle системы (midlleware)) с приостановом.


KGP

PS:Для себя сделал вывод:кластер на 2 компа (RAID 5-го уровня).backup еженедельный разностный с приостановом OR backup разностный (каждый час при idle системы (midlleware)) с приостановом.
Кластер это хорошо, но не забудьте подточить под кластер прикладуху. Ибо failover для прикладухи выглядит как кратковременный обрыв сетки, и она должна уметь реконнектиться и повторять оборванную операцию.Но это уже совсем другой вопрос...