|
БД и СУБД на разных дисках
|
|||
---|---|---|---|
#18+
Пожалуйста, подскажите как разместить БД на другом диске и чем это черевато, т.е. насколько сильно БД привязана к остальной системе различными метаданными? В большинстве реляционных СУБД это очень просто делается, а в Каше не уверен. В результате нужно получить возможность снэпшотить системный диск вместе с СУБД при этом, чтобы БД не попадала в snapshot и соответственно, чтобы новые данные в БД не попадали в лог снэпшота. При этом нужна возможность быстро откатить систему к снэпшоту и потом благополучно тихонечко восстановить из бэкапа БД Бэкап БД сосздается до снэпшота системы Опасаюсь что после возврата к снэпшоту Каше возругается, что у него какая то не та БД, наверно ее можно тогда размонтировать или Каше ее не будет монтировать изначально? ... |
|||
:
Нравится:
Не нравится:
|
|||
04.04.2013, 17:16 |
|
БД и СУБД на разных дисках
|
|||
---|---|---|---|
#18+
снэпшот системного диска предполагается делать при выключенной системе (в виртуалке) ... |
|||
:
Нравится:
Не нравится:
|
|||
04.04.2013, 17:18 |
|
БД и СУБД на разных дисках
|
|||
---|---|---|---|
#18+
sanyock2В большинстве реляционных СУБД это очень просто делается, а в Каше не уверен .С этого места поподробней ... |
|||
:
Нравится:
Не нравится:
|
|||
04.04.2013, 17:23 |
|
БД и СУБД на разных дисках
|
|||
---|---|---|---|
#18+
Guest_2013sanyock2В большинстве реляционных СУБД это очень просто делается, а в Каше не уверен .С этого места поподробней сначала стулья :) ... |
|||
:
Нравится:
Не нравится:
|
|||
04.04.2013, 17:24 |
|
БД и СУБД на разных дисках
|
|||
---|---|---|---|
#18+
речь о внешних снэпшотах дисков (VMWare/ZFS) ... |
|||
:
Нравится:
Не нравится:
|
|||
04.04.2013, 17:28 |
|
БД и СУБД на разных дисках
|
|||
---|---|---|---|
#18+
sanyock2 а в Каше не уверен sanyock2 Опасаюсь что после возвратаХочу понять откуда ветер дует. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.04.2013, 17:35 |
|
БД и СУБД на разных дисках
|
|||
---|---|---|---|
#18+
Guest_2013sanyock2 а в Каше не уверен sanyock2 Опасаюсь что после возвратаХочу понять откуда ветер дует. успокойтесь, штиль ... |
|||
:
Нравится:
Не нравится:
|
|||
04.04.2013, 17:38 |
|
БД и СУБД на разных дисках
|
|||
---|---|---|---|
#18+
sanyock2 , При создании БД Вы можете указать каталог, где хранить файл с БД. БД - это физически один файл cache.dat. Поэтому проблем не должно быть, если у Вас все данные лежат именно в одной БД и под базой Вы не подразумеваете область. PS: Руководство по администрированию Caché версий 5.2, 2008, 2009, 2010 Configuring Databases ... |
|||
:
Нравится:
Не нравится:
|
|||
04.04.2013, 17:50 |
|
БД и СУБД на разных дисках
|
|||
---|---|---|---|
#18+
если не затруднит, пожалуйста, подскажите как переместить существующую базу в общих чертах, детали конечно можно потом в доке прочитать и по идее же еще и логи БД где то хранятся или они тоже в dat? например, в MSSQL 2 файла в DB2 можно db2inst каталог смонтировать с другого диска ну в простеньких Interbase и файловых и так понятно в венде по идее можно junction еще использовать, знать бы точно какие файлы на 100% :) ... |
|||
:
Нравится:
Не нравится:
|
|||
04.04.2013, 18:12 |
|
БД и СУБД на разных дисках
|
|||
---|---|---|---|
#18+
sanyock2, Например, при выключенном каше переносите файл куда нужно, потом в Конфигурация > Локальные базы данных меняете каталог базы данных. Журналы хранятся по умолчанию C:\InterSystems\Cache\mgr\journal, каталоги настраивается примерно тут Система > Конфигурация > Journal Settings Еще вот этот файл очень важен C:\InterSystems\Cache\mgr\cache.wij (write image journal, в русском переводе журнал образа), он там же, где журналы настраивается. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.04.2013, 18:36 |
|
БД и СУБД на разных дисках
|
|||
---|---|---|---|
#18+
(сохраните файл базы перед манипуляциями, в принципе запороть его можно только совсем глупыми действиями, но я стараюсь никому не доверять, особенно себе) ... |
|||
:
Нравится:
Не нравится:
|
|||
04.04.2013, 18:38 |
|
БД и СУБД на разных дисках
|
|||
---|---|---|---|
#18+
Блок А.Н.Еще вот этот файл очень важен c:\InterSystems\Cache\mgr\cache.wijПри лёгких сбоях (типа внепланового reset'a или reboot'a), если базы не пострадали - оно, конечно, да. Но если базы рухнули и их надо восстанавливать из бакапа - то уже не важен. Если по теме, то некоторые мои коллеги поступают так: бакапят Cache по расписанию менеджера задач внутри VM, и бакапят всю VM (с Cache-backup-ами внутри), не останавливая её. После восстановления VM необходимо проверка ^Integrity, и если что-то не так, то "под рукой" оказывается и последний бакап, и журналы. В 99(.9)% случаях ошибок нет, что вызывает у некоторых ложное чувство уверенности, что их и быть не может, что, конечно, неверно. Не то чтобы мне очень нравилась такая технология, но почему бы и нет. Тем более, что лишний раз целостность проверить никогда не худо. Интересно, у многих ли в расписании разблокирована эта задача, и многие ли заглядывают в её протокол, пока что-нибудь не кольнёт? И ещё про виртуалки. Имхо, это потенциальный источник проблем при эксплуатации Cache (о разработке молчу), т.к. всевозможные приёмы оптимизации работы с памятью (memory balooning, overcommit) вредны для системы, которая любит , когда разделяемая память в избытке, и она всегда резидентна. Любит работать на процессорах с известным (желательно большим) количеством ядер, не деля ни с кем их мощность. Есть примеры, когда "наевшись досыта", люди переходили к конфигурациям 1 VM = 1 железный хост (но зачем тогда VM?), либо вообще уходили на "железо". Впрочем, это я о системах с сотнями пользователей. Небольшие, не очень нагруженные системы на VM - почему бы и нет? (можно бы спросить, ради чего в таких системах используется Cache, но не буду ))) ... |
|||
:
Нравится:
Не нравится:
|
|||
04.04.2013, 19:13 |
|
БД и СУБД на разных дисках
|
|||
---|---|---|---|
#18+
Alexey MaslovИ ещё про виртуалки. Имхо, это потенциальный источник проблем при эксплуатации Cache (о разработке молчу), т.к. всевозможные приёмы оптимизации работы с памятью (memory balooning, overcommit) вредны для системы, которая любит , когда разделяемая память в избытке, и она всегда резидентна. Любит работать на процессорах с известным (желательно большим) количеством ядер, не деля ни с кем их мощность. Есть примеры, когда "наевшись досыта", люди переходили к конфигурациям 1 VM = 1 железный хост (но зачем тогда VM?), либо вообще уходили на "железо". при правильном использовании гипервизор добавляет не больше 10% overhead на систему и убирает очень много overhead с админа нужные приёмы выбирабельны, ненужные отключабельны Alexey MaslovВпрочем, это я о системах с сотнями пользователей. Небольшие, не очень нагруженные системы на VM - почему бы и нет? (можно бы спросить, ради чего в таких системах используется Cache, но не буду ))) IBM тоже продвигает VM, и пользователей на их системах нередко тысячи их хотел пояснить цель такого разделения по дискам: диски для БД быстрее, надежнее, дороже и менее доступны (их просто не хватает) двойной лог (свой+FS после внешнего снэпшота) для БД вреден с точки зрения производительности системные диски с точки зрения производительности обычно очень НЕтребовательны к дисковой подсистеме, поэтому ее можно делать из соображений все для удобства админа ... |
|||
:
Нравится:
Не нравится:
|
|||
04.04.2013, 19:59 |
|
БД и СУБД на разных дисках
|
|||
---|---|---|---|
#18+
sanyock2диски для БД быстрее, надежнее, дороже и менее доступны (их просто не хватает) т.е. массивы: RAID10 vs mirror и т.п., ну вы поняли ... |
|||
:
Нравится:
Не нравится:
|
|||
04.04.2013, 20:01 |
|
БД и СУБД на разных дисках
|
|||
---|---|---|---|
#18+
sanyock2хотел пояснить цель такого разделения по дискамДа я в принципе с вами согласен, нормальная схема. Опробовал недавно похожую, но на "железе". Снапшот делал средствами LVM (CentOS 6.3). Поскольку это "железо", мой скрипт может полностью контролировать работу Cache. Демона записи Cache замораживается на время создания снапшота (этого всего несколько секунд), поэтому работа пользователей не останавливается, а файлы БД на диске остаются "чистыми". Далее снапшот бакапится и тут же удаляется, так что он не превращается в длительный тормоз в работе системы. По моей оценке, время жизни снапшота 300GB-ной установки Cache составит в моих условиях 40-50 минут. Плюсы, мне кажется, очевидны: получается действительно полный бакап всей установки Cache, не требующий для запуска дополнительных операций восстановления и/или копирования, только актуальные журналы "подтянуть"... Места под журналы на быстрых дисках мне не то чтобы очень жалко (у нас журналы составляют < 5% объёма БД), просто Cache даёт более ровную загрузку дисков, без резких всплесков, когда журналы находятся на другом физическом диске. Поэтому уместна модификация схемы, когда журналы находятся на отдельном диске. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.04.2013, 10:40 |
|
БД и СУБД на разных дисках
|
|||
---|---|---|---|
#18+
Поделюсь опытом. Уже давно используем схему когда СУБД на одном диске,а базы и журналы в том числе и wij на других дисках(причем на разных). Причем и внутри одной логической базы данные еще разнесены по разным физическим базам - перенаправлением глобалей. Проблем не вызывает уже года 4. А еще два раза перетаскивал базу с сервера на сервер. Тупым копированием cache.dat на одинаково настроенные СУБД. При работе,на сколько знаю, меняются только журналы, wij, сама база, темповая база. Вынесети эти данные из снапшота и проблем с восстановлением не должно быть. Ну и у вас же виртуальки - эксперементируйте ... |
|||
:
Нравится:
Не нравится:
|
|||
05.04.2013, 11:06 |
|
БД и СУБД на разных дисках
|
|||
---|---|---|---|
#18+
Alexey MaslovЕсли по теме, то некоторые мои коллеги поступают так: бакапят Cache по расписанию менеджера задач внутри VM, и бакапят всю VM (с Cache-backup-ами внутри), не останавливая её.Считаю такую практику вредной вплоть до недостойности ее упоминания. Вероятность ошибок гораздо больше, чем кажется, и не оправдывается экономией времени. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.04.2013, 18:03 |
|
БД и СУБД на разных дисках
|
|||
---|---|---|---|
#18+
У меня вообще базы находятся на зеркале, подключенном к основному linux серверу через ethernet ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2013, 17:35 |
|
БД и СУБД на разных дисках
|
|||
---|---|---|---|
#18+
kalin, ECP? ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2013, 17:57 |
|
БД и СУБД на разных дисках
|
|||
---|---|---|---|
#18+
Зачем ESP ? У Linux есть свой сетевой протокол. Через него монтируешь удаленное зеркало и работаешь с ним как с обычным каталогом ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2013, 18:08 |
|
БД и СУБД на разных дисках
|
|||
---|---|---|---|
#18+
И вообще, пытаются на Cache переложить серверные функции. Тот же Linux и сам все умеет делать гораздо лучше ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2013, 18:09 |
|
БД и СУБД на разных дисках
|
|||
---|---|---|---|
#18+
Вот ломается основной сервер, переключаешь зеркало на другую машину и работаешь дальше :) ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2013, 18:10 |
|
БД и СУБД на разных дисках
|
|||
---|---|---|---|
#18+
То, что вы описали, обычно называют СХД или SAN . Зеркало предполагает наличие первичного и вторичного тома (хранилища). Не совсем понятно, что вы имеете в виду, говоря о зеркале. ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2013, 18:22 |
|
БД и СУБД на разных дисках
|
|||
---|---|---|---|
#18+
kalinВот ломается основной сервер, переключаешь зеркало на другую машину и работаешь дальше :) Можно как то поподробнее а таком механизме работы, можно просто ссылок накидать на примеры Были ли случаи по переключению в зеркале, как все это отрабатывалось насколько быстро ? и что если это все под высокой нагрузкой чтения и записи (пиковая скорость записи до 200Mb/s ). ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2013, 18:23 |
|
БД и СУБД на разных дисках
|
|||
---|---|---|---|
#18+
Alexey Maslov, Ну например из простых вот такое http://www.ixbt.com/news/hard/index.shtml?14/53/16 Цена вопроса $100 + два веника в raid1 ... |
|||
:
Нравится:
Не нравится:
|
|||
15.05.2013, 18:51 |
|
|
start [/forum/topic.php?fid=39&msg=38213312&tid=1557166]: |
0ms |
get settings: |
11ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
173ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
60ms |
get tp. blocked users: |
2ms |
others: | 234ms |
total: | 519ms |
0 / 0 |