4 сервера на 1 базу.
Модераторы: Trinity admin`s, Free-lance moderator`s
4 сервера на 1 базу.
Господа, дело в следующем:
Имеется 2 сервера ? Trinity и Cubic.
Trinity ? основной и боевой сервер БД. К нему подключено примерно 150 человек. Из них 100 ? операторы (в основном перенос информации с бумажных носителей). Остальные ? программисты и обычные пользователи самописного ПО. Объем базы ? примерно 19Гб.
Cubic ? OLAP сервер + отладка программ + контекстный поиск для операторов.
По сути, на Cubic?е «варится» та же база, что и на Trinity. Перенос ее осуществляется с помощью бэкапа. Т.е. ночью Trinity бэкапит на Cubic, а затем Cubic ее восстанавливает.
В принципе схема рабочая, если бы не большой объем базы и глюки от MS. Бэкап происходит примерно 1 час и плюс еще столько же восстановление. А глюки ? бэкап может запросто не пройти, причем в логах пишутся какие то совершенно левые сообщения. Иногда бывает так, что бэкап прошел, началось восстановление, но произошел сбой и база «зависла» в состоянии «Suspected», т.е. в не рабочем состоянии. В таком случае приходится заново делать бэкап, заново восстанавливаться на Cubic`е, но т.к. это уже происходит утром и учитывая время, мы получаем мягко говоря геморрой.
Но в целом жить можно.
Однако со временем количество и объем кубов OLAP на сервере Cubic возросло, теперь некоторые из них могут готовиться несколько часов. И если представить себе ситуацию (а такое уже было) когда база восстановилась не ночью, а утром и при этом менеджерам нужно срочно посмотреть какойнить куб, то запуск пересчета некоторых кубов днем может значительно снизить доступность сервера. Другими словами, пересчет кубов на сервере который кроме этого занят контекстным поиском приводит к резкому замедлению как одного, так и другого.
Мы хотим купить еще 2 сервера и разнести на них контекстный поиск и некоторые кубы.
Таким образом, мы получаем уже 4 сервера на которых должна быть одна и та же база данных.
Но в таком случае вопрос переноса базы встает в полный рост.
Можно ли как ни будь добиться сделать так, что бы база у нас была одна и сервера работали с одним экземпляром базы, а не каждый со своей копией?
Или, может быть, кто ни будь предложит свою схему взаимодействия серверов и баз.
Заранее благодарю.
PS: на серверах установлен MS SQL 2000 и MS OLAP.
Имеется 2 сервера ? Trinity и Cubic.
Trinity ? основной и боевой сервер БД. К нему подключено примерно 150 человек. Из них 100 ? операторы (в основном перенос информации с бумажных носителей). Остальные ? программисты и обычные пользователи самописного ПО. Объем базы ? примерно 19Гб.
Cubic ? OLAP сервер + отладка программ + контекстный поиск для операторов.
По сути, на Cubic?е «варится» та же база, что и на Trinity. Перенос ее осуществляется с помощью бэкапа. Т.е. ночью Trinity бэкапит на Cubic, а затем Cubic ее восстанавливает.
В принципе схема рабочая, если бы не большой объем базы и глюки от MS. Бэкап происходит примерно 1 час и плюс еще столько же восстановление. А глюки ? бэкап может запросто не пройти, причем в логах пишутся какие то совершенно левые сообщения. Иногда бывает так, что бэкап прошел, началось восстановление, но произошел сбой и база «зависла» в состоянии «Suspected», т.е. в не рабочем состоянии. В таком случае приходится заново делать бэкап, заново восстанавливаться на Cubic`е, но т.к. это уже происходит утром и учитывая время, мы получаем мягко говоря геморрой.
Но в целом жить можно.
Однако со временем количество и объем кубов OLAP на сервере Cubic возросло, теперь некоторые из них могут готовиться несколько часов. И если представить себе ситуацию (а такое уже было) когда база восстановилась не ночью, а утром и при этом менеджерам нужно срочно посмотреть какойнить куб, то запуск пересчета некоторых кубов днем может значительно снизить доступность сервера. Другими словами, пересчет кубов на сервере который кроме этого занят контекстным поиском приводит к резкому замедлению как одного, так и другого.
Мы хотим купить еще 2 сервера и разнести на них контекстный поиск и некоторые кубы.
Таким образом, мы получаем уже 4 сервера на которых должна быть одна и та же база данных.
Но в таком случае вопрос переноса базы встает в полный рост.
Можно ли как ни будь добиться сделать так, что бы база у нас была одна и сервера работали с одним экземпляром базы, а не каждый со своей копией?
Или, может быть, кто ни будь предложит свою схему взаимодействия серверов и баз.
Заранее благодарю.
PS: на серверах установлен MS SQL 2000 и MS OLAP.
- a_shats
- Advanced member
- Сообщения: 5010
- Зарегистрирован: 27 авг 2002, 10:55
- Откуда: Москва
- Контактная информация:
Простейшее решение (на первый взгляд) - настроить онлайн- репликацию между SQL - серверами (всей кучей). Сложность - в том, что фактически получается "типа кластер" со всеми вытекающими потенциальными неприятностями. С другой стороны, load-balancing кластер есть только в сыроватой пока 2003-ей и соответствующем ей SQL-сервере.
Второй вариант - оффлайн-репликация (по расписанию), но - тогда актуальность данных снизится.
Еще думать надо...
Второй вариант - оффлайн-репликация (по расписанию), но - тогда актуальность данных снизится.
Еще думать надо...
- gs
- Сотрудник Тринити
- Сообщения: 16650
- Зарегистрирован: 23 авг 2002, 17:34
- Откуда: Москва
- Контактная информация:
Первая идея (тупая, но рабочая).
Сделать на дисковой системе один промежуточный том на несколько десятков гигов, доступный всем серверам. Расшарить его при помощи Tivoli SANergy или Veritas. Боевую копию базы на нем держать нельзя, т.к. при работе баз данных будет огромное падение скорости из-за работы механизма блокировок SANergy (он расчитан на большие файлы). К тому же базы в варианте микрософта не знают о существовании друг друга (это вам не Oracle) и работать с одним экземпляром базы просто не умеют. Но этот том можно использовать как промежуточное хранилище для бэкапа. Т.е. боевой сервак бэкапит на него базу, а потом остальные сервера с него восстанавливаются. Работать все это будет намного шустрее, т.к. будет полная скорость дисковой системы, а не IP канала.
Как я уже сказал, это первое, что в голову пришло. Тупо, но вполне работоспособно.
Есть и еще тупее - без софта для шаринга, который денег стоит. Просто боевому серваку дать доступ к томам остальных серверов на общей FC системе, а на время операции бэкапа (бэкапить и копировать на несколько томов) остальные серваки вырубать. Потом включать и делать восстановление каждому со своего тома.
Дальше буду думать в сторону веритасовских приблуд.
Сделать на дисковой системе один промежуточный том на несколько десятков гигов, доступный всем серверам. Расшарить его при помощи Tivoli SANergy или Veritas. Боевую копию базы на нем держать нельзя, т.к. при работе баз данных будет огромное падение скорости из-за работы механизма блокировок SANergy (он расчитан на большие файлы). К тому же базы в варианте микрософта не знают о существовании друг друга (это вам не Oracle) и работать с одним экземпляром базы просто не умеют. Но этот том можно использовать как промежуточное хранилище для бэкапа. Т.е. боевой сервак бэкапит на него базу, а потом остальные сервера с него восстанавливаются. Работать все это будет намного шустрее, т.к. будет полная скорость дисковой системы, а не IP канала.
Как я уже сказал, это первое, что в голову пришло. Тупо, но вполне работоспособно.
Есть и еще тупее - без софта для шаринга, который денег стоит. Просто боевому серваку дать доступ к томам остальных серверов на общей FC системе, а на время операции бэкапа (бэкапить и копировать на несколько томов) остальные серваки вырубать. Потом включать и делать восстановление каждому со своего тома.
Дальше буду думать в сторону веритасовских приблуд.
- a_shats
- Advanced member
- Сообщения: 5010
- Зарегистрирован: 27 авг 2002, 10:55
- Откуда: Москва
- Контактная информация:
Дык... быстрее - именно репликация .
backup/restore вообще не для межсерверного обмена.
Эх, жаль сейчас попробовать нечем...
Zigzug
Кстати: Вы, говорили, что контактируете с разработчиками ?
Суть в следующем: один из старых самопальных вариантов репликации для Interbase сделан был так: на все изменяемые в ходе работы таблицы ставились триггера AFTER INSERT/UPDATE/DELETE. Триггер писал соотв. строку во внешний по отношению к БД файл- вместе с идентификатором "откуда пришло". Также висела сторонняя софтина, отслеживающая изменения этого файла и производящая соотв. действие (которое в него попало) над сервером назначения, после чего - строка с выполненным "действием" удалялась.
Как вариант . Еще - поискать методики, компоненты, софт (агент) для нормальной онлайн-репликации.
В порядке хинта - посмотрите здесь
А вот еще
backup/restore вообще не для межсерверного обмена.
Эх, жаль сейчас попробовать нечем...
Zigzug
Кстати: Вы, говорили, что контактируете с разработчиками ?
Суть в следующем: один из старых самопальных вариантов репликации для Interbase сделан был так: на все изменяемые в ходе работы таблицы ставились триггера AFTER INSERT/UPDATE/DELETE. Триггер писал соотв. строку во внешний по отношению к БД файл- вместе с идентификатором "откуда пришло". Также висела сторонняя софтина, отслеживающая изменения этого файла и производящая соотв. действие (которое в него попало) над сервером назначения, после чего - строка с выполненным "действием" удалялась.
Как вариант . Еще - поискать методики, компоненты, софт (агент) для нормальной онлайн-репликации.
В порядке хинта - посмотрите здесь
А вот еще
- gs
- Сотрудник Тринити
- Сообщения: 16650
- Зарегистрирован: 23 авг 2002, 17:34
- Откуда: Москва
- Контактная информация:
Посмотри тут. Snapshot.
http://www.falconstor.com/softwarecomponents.asp
http://eval.veritas.com/downloads/pro/v ... 7-1-03.pdf
Но это опять же только ускорение процедуры бэкапа.
http://www.falconstor.com/softwarecomponents.asp
http://eval.veritas.com/downloads/pro/v ... 7-1-03.pdf
Но это опять же только ускорение процедуры бэкапа.
- Painter
- member
- Сообщения: 32
- Зарегистрирован: 22 июл 2003, 10:11
- Откуда: Москва
- Контактная информация:
имхо тут порочна идеология
по идее, для анализа что недельной давности данные, что вчерашние - практически равноценны. Анализируется обычно закрытый период (если это учетная система, например, то первичка несколько недель может собираться после совершения некой сделки).
Что это у вас за бизнес-процесс такой, что всем приперло пересчитывать кучу отчетности после добавления нескольких свежих операций?
По теме или несколько оффтопик: в MySQL сделали репликацию на бинарных логах, которые пишет мастер и скачивают слэйвы (их может быть много). В вашу конфигурацию бы все это чУдно вписалось. Трафик невелик (равен количеству апдейтов/инсертов в мастер-базе данных), можно делать сеансы хоть поминутно, можно останавливать любую из машин и т.п.
В MS SQL что-то типа такого есть?
И опять по поводу бизнес-процесса - как-то мне странно, что вы по здоровенной базе что-то по ней по всей обсчитываете часто, что-то мне кажется, что затраты на это дело существенно выше ценности получаемых отчетов... Мне тоже импонировала идея до бесконечности пополняемой БД, однако вот имея данные за несколько лет, для работы нужны только за год-два, и по-моему, так практически везде...
Что это у вас за бизнес-процесс такой, что всем приперло пересчитывать кучу отчетности после добавления нескольких свежих операций?
По теме или несколько оффтопик: в MySQL сделали репликацию на бинарных логах, которые пишет мастер и скачивают слэйвы (их может быть много). В вашу конфигурацию бы все это чУдно вписалось. Трафик невелик (равен количеству апдейтов/инсертов в мастер-базе данных), можно делать сеансы хоть поминутно, можно останавливать любую из машин и т.п.
В MS SQL что-то типа такого есть?
И опять по поводу бизнес-процесса - как-то мне странно, что вы по здоровенной базе что-то по ней по всей обсчитываете часто, что-то мне кажется, что затраты на это дело существенно выше ценности получаемых отчетов... Мне тоже импонировала идея до бесконечности пополняемой БД, однако вот имея данные за несколько лет, для работы нужны только за год-два, и по-моему, так практически везде...
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 10 гостей