|
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
|
|||
---|---|---|---|
#18+
... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2016, 14:53 |
|
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
|
|||
---|---|---|---|
#18+
И еще вопросы: 1) как лучше цеплять активные логи на другом хранилище? варианты: A) ext3 -> iscsi->liotarget->zvol B) nfs->ZFS Наверно второй вариант лучше? Меньше уровней абстракции, быстрее и надежнее? 2) Если бы не было фичи write suspend То был бы шанс проснэпшотить хранилища неодновременно и потом успешно пройти crash recover? Что лучше снэпшотить сначала данные или активные логи? спрашиваю, потому что write suspend не всегда срабатывает, например, при одновременном online бэкапе он не сработвает, но ессно просигнализирует о несработке, т.е. это можно отслеживать и помечать снэпшоты метками safe/unsafe Но все же если про write suspend и снэпшоты забыть, то что для DB2 предпочтительнее выдергивать из розетки в первую очередь для успешного прохождения crash recovery? хранилище с базой или с активными логами? насколько длительным может быть промежуток времени между отключениями этих хранилищь? сколько секунд/минут/ГБ транзакций может пережить DB2 после crash recovery? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2016, 16:37 |
|
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
|
|||
---|---|---|---|
#18+
dbtwoshnickКоманда write resume с моей точки зрения описана более полно в относительно древней версии v8x: https://www.informit.com/articles/article.aspx?p=169530&seqNum=6 SNAPSHOT. The split mirror copy of the database will be initialized as a clone of the primary database. (It will be a working copy that has its own transaction log files. ) Как мне кажется, это то, чего я боялся. Меняется LOG sequence в режиме SNAPSHOT, чтобы отличать ее от оригинальной в режиме MIRROR? Может ли испугаться CDC? и не только? Код: plaintext 1. 2. 3.
Вот у вас жила себе база, в момент t вы сделали ее копию, у вас стали плодиться логи в верхней последовательности. Потом вы решили вернуться на копию, восстановили базу на момент времени t, но по верхней последовательности логов накатываться не стали . Это ключевой момент. Не важно, как именно вы это сделали: с помощью crash recovery, db2inidb as snapshot, db2inidb as mirror/standby + db2 rollforward stop. Базу после этого открыли, она начала генерировать логи с теми же самыми номерами, но в нижней последовательности. Эти логи уже друг с другом не совместимы, это две абсолютно 2 разные цепочки логов. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.09.2016, 23:21 |
|
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
|
|||
---|---|---|---|
#18+
Мне все же кажется, что без write suspend надо сначала снэпшотить активые логи, а потом базу, потому что тогда возможно часть инфы продублируется в базе и логах и потом при последующем crash recovery DB2 заметит это и примет какое-либо правильное решение по этому поводу, позволяющее успешно восстановить базу. А что будет при откате, если сделать наоборот, сначала снэпшотить базу, а потом активные логи? База окажется в состоянии до момента времени, отраженного в самом начале активного лога, т.е. часть инфы будет утеряна, и если DB2 хотя бы заметит это, то наверно в лучшем случае откажется стартовать базу? Все же должны же быть какие то мысли у специалистов по этому поводу, в т.ч. на базе официальной доки? Ведь не исключено без всяких снэпшотов падение нескольких хранилищ почти одновременно, но все же с рассинхронизацией по времени, и наверняка crash recovery рассчитан и на такой случай? Понятно, что еще остается и опция восстановления из бэкапа с архивными логами в случае, если crash recovery не справится со сложившейся ситуацией в базе. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.09.2016, 09:38 |
|
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
|
|||
---|---|---|---|
#18+
может быть, кому-нибудь интересно, получился такой скрипт снэпшотинга: Код: powershell 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. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110.
... |
|||
:
Нравится:
Не нравится:
|
|||
27.09.2016, 18:55 |
|
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
|
|||
---|---|---|---|
#18+
Первый раз столкнулся с проблемой невозможности стартануть базу из снэпшота. На тестовом сервере после репликации снэпшота с пром. сервера. ++ ssh host 'bash -lc '\''db2 restart database XXX write resume'\''' SQL1042C An unexpected system error occurred. SQLSTATE=58004 В db2diag.log много ошибок. Примерно аналогично с другого снэпшота, когда база была под нагрузкой, тоже не стартует. Еще с другого снэпшота взятого позднее в момент времени, когда нагрузки уже не было, на тесте база стартанула нормально. Отсюда препдоложительный вывод: crash recovery не всегда справляется . Можно ли это как то улучшить/побороть? Попробовать db2inidb? разве это чем то поможет? Хотелось бы сначала сделать write suspend, и только потом уже сбросить все dirty pages из буферов, такое невозможно? И кстати, наверно это было бы очень долго, потому что db2stop force насколько я понимаю занимается тем же самым в плане сброса буферов и иногда приходится ждать остановки 5-10 минут, хотя по dstat и iostat видно, что во всю идет запись, обычно очень мелкими блоками. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2016, 09:54 |
|
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
|
|||
---|---|---|---|
#18+
и как после этого разносить table spaces по разным хранилищам? если нет возможности нормально сбросить все dirty pages может быть, надо сначала сделать QUIESCE ? потом сброс буферов, и только потом снэпшот, но ведь тогда все соединения будут потеряны? докаForces all users off the specified instance and database and puts it into a quiesced mode. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2016, 09:58 |
|
Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN
|
|||
---|---|---|---|
#18+
db2diag.log 2016-10-19-09.39.52.586598+300 E154489817E963 LEVEL: Critical PID : 6518 TID : 139769036138240PROC : db2sysc INSTANCE: db2inst NODE : 000 DB : XXX APPHDL : 0-7 APPID: *LOCAL.db2inst.161019043405 AUTHID : ROOT EDUID : 19 EDUNAME: db2agent (XXX) FUNCTION: DB2 UDB, base sys utilities, sqeLocalDatabase::MarkDBBad, probe:10 MESSAGE : ADM14001C An unexpected and critical error has occurred: "DBMarkedBad". The instance may have been shutdown as a result. "Automatic" FODC (First Occurrence Data Capture) has been invoked and diagnostic information has been recorded in directory "/home/db2inst/sqllib/db2dump/FODC_DBMarkedBad_2016-10-19-09.39.52.46 6333_0000/". Please look in this directory for detailed evidence about what happened and contact IBM support if necessary to diagnose the problem. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.10.2016, 10:05 |
|
|
start [/forum/topic.php?fid=43&gotonew=1&tid=1600522]: |
0ms |
get settings: |
9ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
54ms |
get topic data: |
8ms |
get first new msg: |
7ms |
get forum data: |
2ms |
get page messages: |
39ms |
get tp. blocked users: |
1ms |
others: | 306ms |
total: | 443ms |
0 / 0 |