Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Перестал подниматься инкрементальный бэкап
|
|||
|---|---|---|---|
|
#18+
Suse Sles 9 SP3 64 bit + Cache 5.0.20 Сборка 6305U Раньше всегда делал полный бэкап раз в неделю Код: plaintext а инкрементальный каждый день Код: plaintext Бэкапы для проверки копировались на другой сервак и там поднимались. Но недавно (не могу словить ситуацию, что изменилось) перестал накатываться инкрементальный. Т.е. поднимаю полный, потом докатываю инкрементальные. Так вот полный вроде отрабатывает, а когда просит инкрементальный и его подсовываешь, то ругается. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. Полный лог в прицепе. Подскажите, кто чего сможет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2008, 17:17 |
|
||
|
Перестал подниматься инкрементальный бэкап
|
|||
|---|---|---|---|
|
#18+
Глупое может предположение - но у вас дата и время на серверах одинаковое? А также часовой пояс. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2008, 18:46 |
|
||
|
Перестал подниматься инкрементальный бэкап
|
|||
|---|---|---|---|
|
#18+
Блок А.Н.Глупое может предположение - но у вас дата и время на серверах одинаковое? А также часовой пояс. Одинаковые. Мне тоже приходила эта мысль в голову - проверял. У меня пару дней назад база зависла (причину пока не нашёл - перестарт решил проблему) и не сделался очередной инкрементальный бэкап. Сделал я кумулятивный бэкап, то он очень даже хорошо поднялся. Т.е. такое впечатление что в результате недавних глюков где-то завис какой-то инкрементальный бэкап, который сбивает последовательность других инкрементальных. Я посмотрел глобал CacheTaskD и там действительно висел какой-то зависший бэкап с пометой "Running". Я его удалил (нажал в проводнике куба правой кнопкой "Удалить выбранные узлы"). После этого даже перестартовал кашЕ, но ничего не изменилось. Инкрементальный бэкап не идёт. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2008, 19:08 |
|
||
|
Перестал подниматься инкрементальный бэкап
|
|||
|---|---|---|---|
|
#18+
Советую обратиться в службу технической поддержки. Можно сразу собрать статистику с помощью утилиты ^Buttons Код: plaintext и открыть проблему через WRC или написать на адрес support@intersystems.ru . Вадим ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.08.2008, 22:15 |
|
||
|
Перестал подниматься инкрементальный бэкап
|
|||
|---|---|---|---|
|
#18+
А каше что пишет в логе сейчас, когда не стартует? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2008, 05:51 |
|
||
|
Перестал подниматься инкрементальный бэкап
|
|||
|---|---|---|---|
|
#18+
Блок А.Н.А каше что пишет в логе сейчас, когда не стартует? А кашЕ исправно работает. В логе ошибок нету. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2008, 10:04 |
|
||
|
Перестал подниматься инкрементальный бэкап
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. Должно выправиться после очередного full. Если не выправится, надо чистить историю backup'ов, она, помнится, в ^SYS хранится. Дядя Жора, вопрос более общий. Что побудило использовать такую схему backup'ов? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2008, 11:21 |
|
||
|
Перестал подниматься инкрементальный бэкап
|
|||
|---|---|---|---|
|
#18+
Alexey Maslov Код: plaintext 1. В данном случае имеется ввиду когда делался последний инкрементальный бэкап о котором знает база. Если он раньше полного бэкапа то это как раз хорошо и говорит о том, что система ничего не знает об инкрементальных бэкапах которые были позже полного. Я подкладываю ему первый инкрементальный после последнего полного и он его успешно накатывает. Во всяком случае так у меня система прекрасно работала больше года. Alexey MaslovДолжно выправиться после очередного full. Если не выправится, надо чистить историю backup'ов, она, помнится, в ^SYS хранится. Дядя Жора, вопрос более общий. Что побудило использовать такую схему backup'ов? А чем схема плоха? Вот тут вычитал кажется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2008, 13:22 |
|
||
|
Перестал подниматься инкрементальный бэкап
|
|||
|---|---|---|---|
|
#18+
Всё дело в базе /CACHE/mgr/CACHE.DAT На пробной базе этой ошибки не было пока я не заменил эту базу с "боевой" системы. Тут же этот глюк возник и на пробнике и причём на базе ещё прошлогодней. К сожалению эта база не включена в список бэкапируемых баз и мне её восстановить неоткуда. Можно ли эту базу подменить на реальной системе взяв её откуда-то со стороны или с моей пробной системы полугодичной давности? Вижу, что там хранится информация о шедулерах кашЕ и в частности о бэкапах по расписанию. По моему ничего более не типового (относящегося непосредственно к моим данным) там нету. Но если только это, то я могу восстановить эту инфу руками. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2008, 13:25 |
|
||
|
Перестал подниматься инкрементальный бэкап
|
|||
|---|---|---|---|
|
#18+
Можно и подменить CACHE.DAT. А можно попробовать кильнуть историю бакапов: Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2008, 14:34 |
|
||
|
Перестал подниматься инкрементальный бэкап
|
|||
|---|---|---|---|
|
#18+
Восстановление инкрементального бакапа системной базы бессмысленно и опасно, так как сервер с ней работает и делает какие-то изменения, а тут мы еще изменения с другого сервера пытаемся занести. Лучше переустановить каше (с удалением системный баз), можно попробовать перенести их с другого сервера, но из инкрементного юэкапа их лучше убрать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2008, 15:08 |
|
||
|
Перестал подниматься инкрементальный бэкап
|
|||
|---|---|---|---|
|
#18+
Блок А.Н.Лучше переустановить каше (с удалением системный баз), можно попробовать перенести их с другого сервера, но из инкрементного юэкапа их лучше убрать. Так я и хочу перенести, т.к. в бэкап они как раз у меня не входят. Вот и спрашиваю не чреват ли перенос с другого сервака. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2008, 15:35 |
|
||
|
Перестал подниматься инкрементальный бэкап
|
|||
|---|---|---|---|
|
#18+
Alexey MaslovМожно и подменить CACHE.DAT. А можно попробовать кильнуть историю бакапов: Код: plaintext Килнул. Помогло!!! Спасибо, дружище!!! А теперь расскажи, пожалуйста, что эта команда по сути делает. Alexey MaslovСхема плоха тем, что вероятность успешного восстановления БД снижается по мере того, сколько взаимозависимых файлов надо восстанавливать. Сбой на одном из них - и привет. Мы, например, "в поле" используем либо холодный внешний, либо горячий Кашовый, но всегда полный backup. Это наверное так. Но если полный бэкап тянет на хрен знает скоко гектар, а инкрементальный пару десятков метров, то по скорости, времени и нагрузке инкрементальный бэкап необходимое решение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2008, 15:41 |
|
||
|
Перестал подниматься инкрементальный бэкап
|
|||
|---|---|---|---|
|
#18+
Дядя ЖораА теперь расскажи, пожалуйста, что эта команда по сути делаетДык, матчасть стоило бы подучить :) Это команда KILL, удаляет все, что ей подсунут, в данном случае - поддерево глобала. См. доку. Дядя ЖораНо если полный бэкап тянет на хрен знает скоко гектар, а инкрементальный пару десятков метров, то по скорости, времени и нагрузке инкрементальный бэкап необходимое решение.Как показывает практика, где-то до 10-20 (а м.б. и до 50Гб) разумнее делать полный бакап каждый день. Не те это объемы для сегодняшних серверов даже начального уровня. Ну вот к примеру у нас на линуксовом сервере 11Гб бакапятся за 5 мин и еще за 8 мин сжимаются (использую простейший gzip, чтобы работало побыстрее). Сжимаются где-то до 1.7Гб. За неделю имеем: 1.7 * 7 = 11.9 - не пугает ни разу. Если же БД действительно большая - сотни Гб, тогда согласен, одним полным бакапом обойтись будет нелегко. Но я бы к нему добавил кумулятивный бакап, тогда для восстановления будет всегда достаточно двух файлов: последнего full и последнего кумулятивного. Чуть повыше расход дискового пр-ва, чем в твоей схеме, но ей-Богу, диски стоят много дешевле, чем наши нервы :) С терабайтными базами пока что не работал ;) думаю, здесь нужны качественно другие технологии защиты от сбоев: кластеры и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.08.2008, 18:45 |
|
||
|
|

start [/forum/topic.php?fid=39&msg=35473974&tid=1558800]: |
0ms |
get settings: |
7ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
58ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
54ms |
get tp. blocked users: |
1ms |
| others: | 219ms |
| total: | 374ms |

| 0 / 0 |
