4 сервера на 1 базу.

Вопросы программирования БД, их оптимизации, резервирования и восстановления данных.

Модераторы: Trinity admin`s, Free-lance moderator`s

Ответить
Аватара пользователя
Zigzug
Advanced member
Сообщения: 107
Зарегистрирован: 09 сен 2002, 14:17
Откуда: Moscow

4 сервера на 1 базу.

Сообщение Zigzug » 21 июл 2003, 13:41

Господа, дело в следующем:
Имеется 2 сервера ? Trinity и Cubic.
Trinity ? основной и боевой сервер БД. К нему подключено примерно 150 человек. Из них 100 ? операторы (в основном перенос информации с бумажных носителей). Остальные ? программисты и обычные пользователи самописного ПО. Объем базы ? примерно 19Гб.
Cubic ? OLAP сервер + отладка программ + контекстный поиск для операторов.
По сути, на Cubic?е «варится» та же база, что и на Trinity. Перенос ее осуществляется с помощью бэкапа. Т.е. ночью Trinity бэкапит на Cubic, а затем Cubic ее восстанавливает.
В принципе схема рабочая, если бы не большой объем базы и глюки от MS. Бэкап происходит примерно 1 час и плюс еще столько же восстановление. А глюки ? бэкап может запросто не пройти, причем в логах пишутся какие то совершенно левые сообщения. Иногда бывает так, что бэкап прошел, началось восстановление, но произошел сбой и база «зависла» в состоянии «Suspected», т.е. в не рабочем состоянии. В таком случае приходится заново делать бэкап, заново восстанавливаться на Cubic`е, но т.к. это уже происходит утром и учитывая время, мы получаем мягко говоря геморрой.
Но в целом жить можно.
Однако со временем количество и объем кубов OLAP на сервере Cubic возросло, теперь некоторые из них могут готовиться несколько часов. И если представить себе ситуацию (а такое уже было) когда база восстановилась не ночью, а утром и при этом менеджерам нужно срочно посмотреть какойнить куб, то запуск пересчета некоторых кубов днем может значительно снизить доступность сервера. Другими словами, пересчет кубов на сервере который кроме этого занят контекстным поиском приводит к резкому замедлению как одного, так и другого. :evil:
Мы хотим купить еще 2 сервера и разнести на них контекстный поиск и некоторые кубы.
Таким образом, мы получаем уже 4 сервера на которых должна быть одна и та же база данных.
Но в таком случае вопрос переноса базы встает в полный рост.
Можно ли как ни будь добиться сделать так, что бы база у нас была одна и сервера работали с одним экземпляром базы, а не каждый со своей копией?
Или, может быть, кто ни будь предложит свою схему взаимодействия серверов и баз.
Заранее благодарю.

PS: на серверах установлен MS SQL 2000 и MS OLAP.

Аватара пользователя
a_shats
Advanced member
Сообщения: 5010
Зарегистрирован: 27 авг 2002, 10:55
Откуда: Москва
Контактная информация:

Сообщение a_shats » 21 июл 2003, 17:23

Простейшее решение (на первый взгляд) - настроить онлайн- репликацию между SQL - серверами (всей кучей). Сложность - в том, что фактически получается "типа кластер" со всеми вытекающими потенциальными неприятностями. С другой стороны, load-balancing кластер есть только в сыроватой пока 2003-ей и соответствующем ей SQL-сервере.
Второй вариант - оффлайн-репликация (по расписанию), но - тогда актуальность данных снизится.
Еще думать надо...

Аватара пользователя
gs
Сотрудник Тринити
Сотрудник Тринити
Сообщения: 16622
Зарегистрирован: 23 авг 2002, 17:34
Откуда: Москва
Контактная информация:

Сообщение gs » 21 июл 2003, 17:25

Первая идея (тупая, но рабочая).
Сделать на дисковой системе один промежуточный том на несколько десятков гигов, доступный всем серверам. Расшарить его при помощи Tivoli SANergy или Veritas. Боевую копию базы на нем держать нельзя, т.к. при работе баз данных будет огромное падение скорости из-за работы механизма блокировок SANergy (он расчитан на большие файлы). К тому же базы в варианте микрософта не знают о существовании друг друга (это вам не Oracle) и работать с одним экземпляром базы просто не умеют. Но этот том можно использовать как промежуточное хранилище для бэкапа. Т.е. боевой сервак бэкапит на него базу, а потом остальные сервера с него восстанавливаются. Работать все это будет намного шустрее, т.к. будет полная скорость дисковой системы, а не IP канала.

Как я уже сказал, это первое, что в голову пришло. Тупо, но вполне работоспособно.

Есть и еще тупее - без софта для шаринга, который денег стоит. Просто боевому серваку дать доступ к томам остальных серверов на общей FC системе, а на время операции бэкапа (бэкапить и копировать на несколько томов) остальные серваки вырубать. Потом включать и делать восстановление каждому со своего тома.

Дальше буду думать в сторону веритасовских приблуд.

Аватара пользователя
gs
Сотрудник Тринити
Сотрудник Тринити
Сообщения: 16622
Зарегистрирован: 23 авг 2002, 17:34
Откуда: Москва
Контактная информация:

Сообщение gs » 21 июл 2003, 17:30

Но пока все мысли крутятся вокруг того, как сделать быстрее backup/restore. Просто не представляю, как иначе разобраться с MS SQL (разве что один СИЛЬНЫЙ сервак поставить и все на нем запустить - но это сам знаешь).

Аватара пользователя
a_shats
Advanced member
Сообщения: 5010
Зарегистрирован: 27 авг 2002, 10:55
Откуда: Москва
Контактная информация:

Сообщение a_shats » 21 июл 2003, 18:06

Дык... быстрее - именно репликация ;) .
backup/restore вообще не для межсерверного обмена.
Эх, жаль сейчас попробовать нечем...
Zigzug
Кстати: Вы, говорили, что контактируете с разработчиками ?
Суть в следующем: один из старых самопальных вариантов репликации для Interbase сделан был так: на все изменяемые в ходе работы таблицы ставились триггера AFTER INSERT/UPDATE/DELETE. Триггер писал соотв. строку во внешний по отношению к БД файл- вместе с идентификатором "откуда пришло". Также висела сторонняя софтина, отслеживающая изменения этого файла и производящая соотв. действие (которое в него попало) над сервером назначения, после чего - строка с выполненным "действием" удалялась.
Как вариант ;) . Еще - поискать методики, компоненты, софт (агент) для нормальной онлайн-репликации.
В порядке хинта - посмотрите здесь
А вот еще

ВТБ!
free-lance moderator
Сообщения: 213
Зарегистрирован: 06 ноя 2002, 11:00
Контактная информация:

Сообщение ВТБ! » 22 июл 2003, 10:34

gs писал(а):Но пока все мысли крутятся вокруг того, как сделать быстрее backup/restore.
Остановить SQL-серверы и сделать "мгновенную" копию файлов нужной БД.

Аватара пользователя
Zigzug
Advanced member
Сообщения: 107
Зарегистрирован: 09 сен 2002, 14:17
Откуда: Moscow

Сообщение Zigzug » 23 июл 2003, 09:38

Можно подробнее про "сделать "мгновенную" копию файлов нужной БД".
Что значит "мгновенная" копия?

Аватара пользователя
gs
Сотрудник Тринити
Сотрудник Тринити
Сообщения: 16622
Зарегистрирован: 23 авг 2002, 17:34
Откуда: Москва
Контактная информация:

Сообщение gs » 23 июл 2003, 10:21

Посмотри тут. Snapshot.
http://www.falconstor.com/softwarecomponents.asp
http://eval.veritas.com/downloads/pro/v ... 7-1-03.pdf

Но это опять же только ускорение процедуры бэкапа.

Аватара пользователя
Painter
member
Сообщения: 32
Зарегистрирован: 22 июл 2003, 10:11
Откуда: Москва
Контактная информация:

имхо тут порочна идеология

Сообщение Painter » 23 июл 2003, 18:06

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

Что это у вас за бизнес-процесс такой, что всем приперло пересчитывать кучу отчетности после добавления нескольких свежих операций? :shock:

По теме или несколько оффтопик: в MySQL сделали репликацию на бинарных логах, которые пишет мастер и скачивают слэйвы (их может быть много). В вашу конфигурацию бы все это чУдно вписалось. Трафик невелик (равен количеству апдейтов/инсертов в мастер-базе данных), можно делать сеансы хоть поминутно, можно останавливать любую из машин и т.п.

В MS SQL что-то типа такого есть?

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

Аватара пользователя
Zigzug
Advanced member
Сообщения: 107
Зарегистрирован: 09 сен 2002, 14:17
Откуда: Moscow

Сообщение Zigzug » 12 авг 2003, 16:34

В кратце - пока остановились на репликации средствами MS SQL.

Аватара пользователя
gs
Сотрудник Тринити
Сотрудник Тринити
Сообщения: 16622
Зарегистрирован: 23 авг 2002, 17:34
Откуда: Москва
Контактная информация:

Сообщение gs » 12 авг 2003, 16:57

Одобрям :)

Аватара пользователя
Zigzug
Advanced member
Сообщения: 107
Зарегистрирован: 09 сен 2002, 14:17
Откуда: Moscow

Сообщение Zigzug » 12 авг 2003, 17:35

2 gs

Не знаю, грустно все это. И тупо как-то....
И глючить все будет...
Я это чувствую.... :cry:

Аватара пользователя
gs
Сотрудник Тринити
Сотрудник Тринити
Сообщения: 16622
Зарегистрирован: 23 авг 2002, 17:34
Откуда: Москва
Контактная информация:

Сообщение gs » 12 авг 2003, 18:00

Ну нету другого пути с MS SQL. Я неделю землю рыл. А оракл вы не хотите (хотя я это понимаю).

Аватара пользователя
Zigzug
Advanced member
Сообщения: 107
Зарегистрирован: 09 сен 2002, 14:17
Откуда: Moscow

Сообщение Zigzug » 13 авг 2003, 10:22

Лично я "за" Оракл.
Но как представлю себе объем переделок.... :(

Ответить

Вернуться в «Серверы - ПО, Базы Данных и их использование»