|
После восстановления 0 уровня накатывается только один логический журнал
|
|||
---|---|---|---|
#18+
Всем привет ! Linux CentOS 5, Informix Dynamic Server Version 9.40.UC6 Натолкнулся на какую то фигню - После восстановления 0 уровня накатывается только один логический журнал ... Все по порядку : /opt/informix/etc/onconfig : Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9.
Логи оттаскиваются скриптом /usr/scripts/bin/inf_alarm.sh который создает fifo и с одной стороны запускат ontape -a , а с другой cat fifo | gzip -c >testcomp_log.StartNumber-EndNumber.gz Это бэкап 0 уровня и логи за ним : Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9.
1. Разворачиваю бэкап 0 уровня : Код: plaintext 1. 2. 3. 4. 5.
Please mount tape 1 on /backup/testcomp_base and press Return to continue ... <ENTER> ... Continue restore? (y/n)y Do you want to back up the logs? (y/n)n В логе : Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41.
Restore a level 1 archive (y/n) n Do you want to restore log tapes? (y/n)y Roll forward should start with log number 255 Please mount tape 1 on /backup/testcomp_log and press Return to continue ... В логе : Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
Запускаю с другой консоли : Код: plaintext 1. 2. 3.
Жму ENTER на сообщении Please mount tape 1 on /backup/testcomp_log and press Return to continue ... В логе : Код: plaintext 1. 2. 3. 4.
Do you want to restore another log tape? (y/n)n Далее onmode -m и вижу, что база в состоянии после лога 255 и до 256 ... если же на предложение Do you want to restore another log tape? (y/n) сказать 'y' и дать ему Код: plaintext 1.
То он накатит 256 лог ... ну и т.д... Так я помру догонять базу до актуала ... Почему сконкатенированный поток из логов ( cat /backup/11/testcomp_log* | gzip -cd >$LFIFO ) воспринимается как один первый лог ? В семерке тот же способ вроде работал правильно ... поток логов воспринимался нормально и догонялся правильно ... P.S. Если сгрудить все логи в один простой файл Код: plaintext 1. 2.
Может есть у кого какаие мысли ? ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2009, 12:22 |
|
После восстановления 0 уровня накатывается только один логический журнал
|
|||
---|---|---|---|
#18+
(в качестве предположения) ...в одном из очень давних обсуждений (лень искать ссылки) упоминалось, что (на вашем примере) в команде: Код: plaintext
Т.е. привести к виду: Код: plaintext
Где blockread (у нас) - самописная Си-программа в неск. строк, могу дать исходники. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2009, 12:41 |
|
После восстановления 0 уровня накатывается только один логический журнал
|
|||
---|---|---|---|
#18+
svat2(в качестве предположения) ...в одном из очень давних обсуждений (лень искать ссылки) упоминалось, что (на вашем примере) в команде: Код: plaintext
Т.е. привести к виду: Код: plaintext
Где blockread (у нас) - самописная Си-программа в неск. строк, могу дать исходники. http://www.sql.ru/forum/actualthread.aspx?tid=369246&hl=blockread#3490788 ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2009, 12:50 |
|
После восстановления 0 уровня накатывается только один логический журнал
|
|||
---|---|---|---|
#18+
Это тут не причем - восстановление то идет нормально и все читается ... Смысл вопроса совсем не в этом. Про blockread тема была другой - там на каких то юниксах типа Irix или солярке pipe не выдавал блоками и приходилось так делать. Здесь это не нужно. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2009, 12:50 |
|
После восстановления 0 уровня накатывается только один логический журнал
|
|||
---|---|---|---|
#18+
defocus Это тут не причем - восстановление то идет нормально и все читается ... ясно, я не вник, предположение отбрасываем :) defocus Так я помру догонять базу до актуала ... ... Может есть у кого какаие мысли ? если суть вопроса в вышезацитированном, то это можт АнатоЛой подскажет, у него схожая проблема была, можт он ее как решил... Cхематически подход был в объединении и "ontape -l" и "cat ... > $FIFO" в один скрипт, в цикле по файлам логов, проблема была только в подсовывании ontape-у злощасного подтверждения "y". Ибо действительно, при большом количестве логов - утомляет... ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2009, 13:10 |
|
После восстановления 0 уровня накатывается только один логический журнал
|
|||
---|---|---|---|
#18+
svat2если суть вопроса в вышезацитированном, то это можт АнатоЛой подскажет, у него схожая проблема была, можт он ее как решил... Cхематически подход был в объединении и "ontape -l" и "cat ... > $FIFO" в один скрипт, в цикле по файлам логов, проблема была только в подсовывании ontape-у злощасного подтверждения "y". Ибо действительно, при большом количестве логов - утомляет...expect ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2009, 13:51 |
|
После восстановления 0 уровня накатывается только один логический журнал
|
|||
---|---|---|---|
#18+
defocus Так я помру догонять базу до актуала ... Эээ... Из форумчан никто не помер от этого?! :) defocus Почему сконкатенированный поток из логов ( cat /backup/11/testcomp_log* | gzip -cd >$LFIFO ) воспринимается как один первый лог ? Ну... Во первых, где гарантия что "cat /backup/11/testcomp_log*" запихнёт их в ПРАВИЛЬНОЙ последовательности?! А во-вторых, дело, скорее всего, непосредственно в ontape. Например, ontape может после обнаружения признака конца первого лога (ну или отчитав кол-во байт по длине лога), просто заканчивать обработку потока, а получив подтверждение о готовности следующего: закрывать и открывать поток заново... :( defocus В семерке тот же способ вроде работал правильно ... поток логов воспринимался нормально и догонялся правильно ... Дааа??? defocus Может есть у кого какаие мысли ? Пессимистичная: поставить восстановление, и спокойно пить кофе на кухне у меня так и не получилось. Оптимистичная: добиться того, чтобы на загрузку одного лога требовалось только несколько нажатий клавиши - уже давно реализованная задача (причём не мной :)). svat2 как раз про неё упоминал. Не полный фен-шуй, но и раздражения УЖЕ особо не вызывает :). Суть в следующем: 1. Запускаем процесс, который в цикле в ПРАВИЛЬНОМ порядке, скармливает ОТДЕЛЬНО каждый лог в LFIFO. 2. Запускаем ontape, который начинает задавать свои любимые вопросы. Вот тут и приходится нажимать на эти пресловутые клавиши: "y", "Enter", "Enter". И эта обратная связь со строны "оператора-администратора" необходима, поскольку между событиями "ontape закончил читать лог N" и "ontape начал читать лог N+1" процессу-кормильцу очень нужно успеть подключить шланг лога N+1 к LFIFO. Иначе возникают неприятные накладки (не пытайте - не вспомню :( ). Кроме того, 1) с одной стороны, иногда ontape открывает текущий лог дважды :(. 2) с другой стороны, если ontape'у скормить один и тот же лог несколько раз, ontape повторы просто игнорирует (что видно только по подозрительно быстрой скорости обработки). В результате приходиться процессу-кормильцуLFIFO в цикле каждый лог скармливать дважды. Вроде всё... Ну разве что можно добавить, что если порыться в инете - то эта схема найдётся уже реализованным скриптом где-нить на просторах IIUG, а также можно эту схему организовать в одном скрипте... To Журавлёв: какое из русских значений слова expect подразумевается? :) ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2009, 19:42 |
|
После восстановления 0 уровня накатывается только один логический журнал
|
|||
---|---|---|---|
#18+
АнатоЛой To Журавлёв: какое из русских значений слова expect подразумевается? :) To АнатоЛой: :) Толик, подразумевается название утилиты. См. http://ru.wikipedia.org/wiki/Expect ... хотя мне больше "по душе" empty (cм. http://empty.sourceforge.net/ а более подробно и по-русски: http://www.opennet.ru/base/dev/interactive_tools.txt.html) Единственное, что сейчас нету тестовой железяки, на которой бы можно было бы, никому не мешая, испытать одну из этих утилит в своих скриптах... ... |
|||
:
Нравится:
Не нравится:
|
|||
18.03.2009, 20:06 |
|
После восстановления 0 уровня накатывается только один логический журнал
|
|||
---|---|---|---|
#18+
АнатоЛойВо первых, где гарантия что "cat /backup/11/testcomp_log*" запихнёт их в ПРАВИЛЬНОЙ последовательности?! В данном случае логи именуются -rw-rw---- 1 informix informix 7427 Mar 18 10:37 testcomp_log.255-255.gz -rw-rw---- 1 informix informix 5434 Mar 18 10:40 testcomp_log.256-256.gz -rw-rw---- 1 informix informix 893 Mar 18 10:41 testcomp_log.257-257.gz -rw-rw---- 1 informix informix 4600 Mar 18 10:41 testcomp_log.258-258.gz "*" в никсах выдает список отсортированный по алфавиту, поэтому в ДАННОМ случае последовательность будет правильной. Другие случаи я не рассматриваю. АнатоЛойНапример, ontape может после обнаружения признака конца первого лога (ну или отчитав кол-во байт по длине лога), просто заканчивать обработку потока, а получив подтверждение о готовности следующего: закрывать и открывать поток заново... :( Как тогда объяснить тот факт, что восстановление не через pipe (из обычного файла) приводит к тем же самым результатам (накатывается только первый лог) ? Поясню еще раз - сливаем содержимое всех логов в один ПРОСТОЙ файл (не pipe) cat /backup/11/testcomp_log* | gzip -cd >/backup/testcomp_log и при восстановлении из него накатывается только первы лог. Если слить в него логи 256-258, то восстановится только 256 лог, ну и т.д по индукции ... pipe тут явно ни при чем. defocusВ семерке тот же способ вроде работал правильно ... поток логов воспринимался нормально и догонялся правильно ... Если смогу - сегодня проверю и отпишу. Как то все грустно получается...Чего то я не понимаю - ведь наверное с ленточкой таких проблем не возникает ? Типа вставьте ленточку с логами - вставляем и за один раз накатываем все что на ней есть ? или нет ? Может я использую неправильную схему хранения и оттаскивания логов ? Напомню еще раз мою схему : Скриптом обрабатывается сигнал переключения на следующий лог и делается ontape -a в pipe, который с другой стороны подхватывается гзипом и укладывается куда надо с соответствующими номерами логов. Если можно делать это как то удобнее - скажите пожалуйста. С expect-ом проблем нет, могу и с ним скрипт написать... но по моему опыту работы с ним - зачастую он сильно глючит и делает то, чего не ожидается от него.. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.03.2009, 09:43 |
|
После восстановления 0 уровня накатывается только один логический журнал
|
|||
---|---|---|---|
#18+
defocusАнатоЛойНапример, ontape может после обнаружения признака конца первого лога (ну или отчитав кол-во байт по длине лога), просто заканчивать обработку потока, а получив подтверждение о готовности следующего: закрывать и открывать поток заново... :( Как тогда объяснить тот факт, что восстановление не через pipe (из обычного файла) приводит к тем же самым результатам (накатывается только первый лог) ? Поясню еще раз - сливаем содержимое всех логов в один ПРОСТОЙ файл (не pipe) cat /backup/11/testcomp_log* | gzip -cd >/backup/testcomp_log и при восстановлении из него накатывается только первы лог. Если слить в него логи 256-258, то восстановится только 256 лог, ну и т.д по индукции ... pipe тут явно ни при чем. В моём предположении меняем "поток" на "файл" - и получаем тот же результат. Думаю, всё-таки стоит принимать во внимание, что ontape нацелен был на работу с лентами... И не зря он [она?!] пошленько переспрашивает не только про "хотите ли продолжить?", но и про "вставили ли?"... П.С.: В 11-ке вон ontape уже сам в каталог складывает и файлы нумерует, и сам потом оттуда их подымает при восстановлении... defocus Как то все грустно получается...Чего то я не понимаю - ведь наверное с ленточкой таких проблем не возникает ? Типа вставьте ленточку с логами - вставляем и за один раз накатываем все что на ней есть ? или нет ? Честно, сам я ленту не только в руках не держал, но наверное и не видел даже :) ... |
|||
:
Нравится:
Не нравится:
|
|||
19.03.2009, 12:56 |
|
После восстановления 0 уровня накатывается только один логический журнал
|
|||
---|---|---|---|
#18+
В семерке таже фигня. Ладно. понятно. буду писать на expect. Всем спасибо ! ... |
|||
:
Нравится:
Не нравится:
|
|||
19.03.2009, 13:18 |
|
После восстановления 0 уровня накатывается только один логический журнал
|
|||
---|---|---|---|
#18+
defocusЕсли можно делать это как то удобнее - скажите пожалуйста. А почему не хотите попробовать OnBar с каким-то Storage Manager-ом, тем же ISM ? Все достаточно удобно, автоматизировано, можно сжимать архивы на лету и т.д. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.03.2009, 14:52 |
|
|
start [/forum/topic.php?fid=44&msg=35879067&tid=1607865]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
64ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
54ms |
get tp. blocked users: |
1ms |
others: | 14ms |
total: | 176ms |
0 / 0 |