Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / IBM DB2, WebSphere, IMS, U2, etc Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2 3      [все]
 Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
Добрый день,

Переключение в режим автоматического архивирования на другое хранилище или TSM (за пределы локального ZFS DataSet) не подходит, потому что пользуемся снэпшотами на хранилище в режиме DB2 write suspend.

Если архивировать автоматически, то при откате на снэпшот база не сможет рестартануть из-за несоответствия более ранних активных логов на снэпшоте более поздним архивным логам.

Поэтому хотелось бы самостоятельно копировать архивные логи в другое хранилище.

Например, с помощью rsync или существуют другие способы?

Как отделить мух от котлет архивные логи от активных, лучше бы они были в разных каталогах.
Наверно надо поменять значение LOGARCHMETH1 на DISK типа LOG/ARCHIVE, но указать не другое хранилище, а всего лишь другой каталог того же самого DataSet ZFS, которое снэпшотится? Тогда при откате на снэпшот активные логи будут соответствовать архивным на том же датасете.

А при очередном запуске rsync из крона (или в цикле) логи из каталога LOG/ARCHIVE будут копироваться rsync-ом на другое хранилище (бэкап сервер), туда же, где лежат бэкапы.

А потом уже с бэкап сервера полные бэкапы, дельты и логи будут неспешно уходить на TSM в режиме "WINDOWS DOMAIN" если не ошибаюсь, т.е. обычным копированием файлов.

Так получится?
17 сен 16, 04:39    [19676399]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
снэпшоты делаются так:

suspend_db()
{
Name=$1;

echo "===== Suspending database $Name";
db2 terminate;
db2 archive log for db $Name;
db2 connect to $Name;
db2 set write suspend for database;

}

resume_db()
{
Name=$1;

echo "===== Resuming database $Name";

db2 terminate;
db2 connect to $Name;
db2 set write resume for database;

}

suspend_db DBName;
timeout 30s ssh z1 "/utils/create_snapshot.sh data/database safe_suspended_db2_$1; sync";
resume_db DBName;
17 сен 16, 04:45    [19676406]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
забыл написать,

между suspend и zfs snapshot делается:

free && sync && echo 3 > /proc/sys/vm/drop_caches && sync && free;

для файловой системы на хосте DB2
17 сен 16, 04:47    [19676407]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
хотел бы отметить причину использования ZFS снэпшотов

правильно ли я понимаю, что длительность восстановления базы из бэкапа прямо пропорциональна ее размеру при прочих равных условиях?

т.е. например, если база 100GB восстанавливается из бэкапа с соседнего ZFS сервера за 1-2 часа, с TSM более чем за 5 часов

то откат на снэпшот ZFS происходит за несколько секунд, и потом еще надо подождать минут 10 выполнения следующих команд:

ssh $ClientHost "bash -lc 'db2 restart database "$Name" write resume'";
ssh $ClientHost "db2 terminate; #db2 activate database $Name";
ssh $ClientHost "bash -lc 'db2 set write resume for database'";
ssh $ClientHost "db2 connect to $Name; db2 terminate";


прошу не разводить холивар на тему "снэпшоты - это не бэкапы"

1) во первых потому-что причина отката - бывает возврат на предыдущую точку до какого-либо действия типа установки новой версии или запуска скрипта

2) во вторых потому что обычный бэкап делается да (ессно на другое хранилище), и архивирование логов тоже планируется по схеме, описанной выше

3) еще делается синхронизация с одного сервера ZFS на другой рядом стоящий, что является почти вторым бэкапом ( но без возможности доката логов на такой снэпшот)


так вот, например, если через год объем базы вырастет в 10 раз до 1 ТБ, то если мы хотим сделать точку сохранения перед установкой новой версии и потом захотим вернуться на нее, то в случае использования:

1) ZFS снэпшота нам придется ждать те же самые 10 минут выполнения crash recovery, что и для базы в 10 раз меньшего объема

2) DB2 бэкапа придется восстанавливать в течение многих часов и потом еще докатывать логи. очень весело ...

Или я чего-то не понимаю?

В случае выхода из строя оборудования хранилища данных (например, оба диска зеркала сразу одновременно)
таки пришлось бы восстанавливаться из бэкапа (для этого он и делается), но это уже совсем другая история.

В общем правильно ли я описал, как можно совместить снэпшотирование с архивированием логов? - это самый главный вопрос ветки.
17 сен 16, 09:46    [19676473]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4876
dbtwoshnick,

Добрый день.

Вы как-то странно пытаетесь восстанавливать копии.
Почему вы не пользуетесь db2inidb?
http://www.ibm.com/support/knowledgecenter/SSEPGG_9.7.0/com.ibm.db2.luw.admin.cmd.doc/doc/r0004473.html

Если вы хотите вернуться на копию базы, то вам после восстановления датасета достаточно сделать
db2inidb mydb as snapshot

О каком несоответствии между активными и архивными логами вы говорите? Вы ведь полностью возвращаетесь к состоянию файловой системы, которая была при качалке копии.
Или вы логи держите на другом датасета, который не копируется?
17 сен 16, 10:22    [19676499]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4876
Mark Barinstein,

качалке == начале
17 сен 16, 10:24    [19676501]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4876
dbtwoshnick,

Отделять архивные и активные логи надо, если будет желание восстанавливаться с последующим накатом по логам.
Тогда после восстановления вы стираете активные логи (но только с теми именами, которые есть в архивном пути к моменту восстановления) и делаете доступными архивные логи, накопившиеся после операции снепшота. Т.е. вы можете поставить logarchmeth1 в disk или tsm. Главное, чтобы эти логи потом были доступными для rollforward.

archive log перед write suspend делать не надо - при write suspend это делается автоматически.
17 сен 16, 10:35    [19676514]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
Mark Barinstein
О каком несоответствии между активными и архивными логами вы говорите? Вы ведь полностью возвращаетесь к состоянию файловой системы, которая была при качалке копии.
Или вы логи держите на другом датасета, который не копируется?


Насколько я понимаю, для возможности восстановления базы из бэкапа с rollforward
бэкапы (offline или онлайн, полные и инкрементальные) и архивные логи нужно хранить на хранилище, отличном от хранилища, на котором расположены базы данных DB2

Тогда в случае невосстановимого сбоя основного хранилища можно было бы заменить железо основного хранилища и восстановить на него базу из бэкапа (с другого бэкап хранилища) с rollforward, например, до point in time в логах, находящихся на другом хранилище вместе с бэкапами

Начитавшись про эти замечательные возможности DB2 около года назад, я сделал NFS mount /mnt/prom-logs

установил параметр MIRRORLOGPATH:
баз db2 update db config using MIRRORLOGPATH /mnt/prom-logs/$DBName;

в результате при первом коннекте DB2 много отправляла по сетке на NFS маунт и вроде бы было все хорошо,

НО, решив проверить возможность отката на снэпшот, я запустил обычные для этого операции, которые раньше всегда работали без сбоев, при первом коннекте к DB2 или restart db не помню точно, получил очень долгое ожидание порядка часа и потом ошибку не помню с каким номером, даже сначала напугался, что моя схема снэпшотов работает неправильно ...

но потом откатился на чуть более ранний снэпшот, который сделал перед изменениями MIRRORLOGPATH
и restart db прошел как обычно без каких либо ошибок за 10 минут

Отсюда я сделал вывод, что если MIRRORLOGPATH указывает на каталог за пределами ZFS снэпшота, на которые происходит откат файловой системы, то при рестарте базы данных, когда она пытается сделать crash recovery, то видит, что каталог MIRRORLOGPATH содержит какие-то непонятные логи из будущего, которое никогда не наступит после отката на снэпшот, долго думает, очень много шлет по NFS не помню в каких направлениях и в результате вываливается с ошибкой.

Поэтому на данный момент считаю (предположение, подтвержденное моим опытом), что архивные логи можно выводить за пределы снэпшотируемого каталога DB2 только обычным копированием из каталога (с архивными логами) внутри снэпшота.

НО восстанавливаться таким способом из бэкапа еще не пробовал, предстоит проверить.

Если же настроить DB2 на автоматическую (например, средствами DB2 MIRRORLOGPATH) архивацию логов за пределы снэпшотируемой файловой системы, то происходит вышеописанный конфликт несоответствия логов или еще чего-то при рестарте после отката.

Хотя может быть, DB2 не понравилось несоответствие зеркала логов основному каталогу логов внутри снэпшота, который был LOGRETAIN.

С LOGARCHMETH1 я такого не пробовал (за пределами снэпшота), но экспериментировать больше не хочется в этом плане, потому что неизвестно когда оно еще раз сбойнет. Если уж откатываться на снэпшот, то чтобы настройки базы внутри снэпшота не вылазили за пределы этого снэпшота.

За пределы снэпшота (к бэкапам и логам на другом хранилище) в моей предложенной схмеме работы может обратиться только db2 restore, мне кажется так безопаснее и беспроблемнее.
17 сен 16, 11:10    [19676557]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
Mark Barinstein
archive log перед write suspend делать не надо - при write suspend это делается автоматически.


у меня db2 "archive log" теперь вынесены до suspend, чтобы надолго не саспендить, потому что саспендится несколько баз

db2 archive log for db DB3
db2 archive log for db DB2
db2 archive log for db DB1

suspend_db DB1
suspend_db DB2
suspend_db DB3

snapshot

resume_db DB3
resume_db DB2
resume_db DB1

мне кажется, так будет меньше простоя
17 сен 16, 11:15    [19676561]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
db2top
Guest
dbtwoshnick
Начитавшись про эти замечательные возможности DB2 около года назад, я сделал NFS mount /mnt/prom-logs

установил параметр MIRRORLOGPATH:
баз db2 update db config using MIRRORLOGPATH /mnt/prom-logs/$DBName;


MIRRORLOGPATH это зеркало для АКТИВНЫХ логов
Чтобы откладывать АРХИВНЫЕ логи на NFS-шару нужно использовать LOGARCHMETH1/2
17 сен 16, 11:23    [19676571]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
Mark Barinstein
Отделять архивные и активные логи надо, если будет желание восстанавливаться с последующим накатом по логам.

Ну как бы желания особого нет конечно заниматься восстановлением db2 restore :) но если придется (не дай Бог конечно), надо, чтобы такая возможность была, включая докат по архивным логам.

Mark Barinstein
Тогда после восстановления

В смысле после отката на снэпшот или после восстановления из бэкапа т.е. после db2 restore ?


Mark Barinstein
вы стираете активные логи (но только с теми именами, которые есть в архивном пути к моменту восстановления) и делаете доступными архивные логи, накопившиеся после операции снепшота. Т.е. вы можете поставить logarchmeth1 в disk или tsm. Главное, чтобы эти логи потом были доступными для rollforward.

Не пойму, вы говорите о восстановлении которое состоит и из отката на снэпшот и одновременно о докате логов

Разве логи можно докатывать в любой момент отличный от "после db2 restore"?

Т.е. ну откатился я на снэпшот, зачем мне удалять активные логи? я ведь все равно не смогу сделать rollforward? максумум, что в данном случае возможно по логам - это crash recovery после команду restart db with write resume, или я ошибаюсь?
и как раз тут важно сохранить старые активные логи из снэпшота и чтобы DB2 не лез за архивными логами куда-то за пределы снэпшота или я не прав?
17 сен 16, 11:26    [19676575]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
db2top
Guest
dbtwoshnick
правильно ли я понимаю, что длительность восстановления базы из бэкапа прямо пропорциональна ее размеру при прочих равных условиях?

т.е. например, если база 100GB восстанавливается из бэкапа с соседнего ZFS сервера за 1-2 часа, с TSM более чем за 5 часов


Скорость бекапа/рестора зависит от многих вещей : скорости чтения/записи на источнике/приемнике, скорости среды передачи данных, параллелизма, количества и размера буферов, размера util_heap_size, распредения данных по табличным пространствам, компрессии т .д

100GB за 5 часов это очень плохо.
Из собственного недавнего: тестовая база в 1.3 TB ресторилась за 6 часов с TSM'а (некомпрессный бекап с LTO-6 ленты) и 4 часа с компрессного бекапа на NFS-шаре сервера с резервной площадки. В обоих случая по обе стороны гигабитные линки.
17 сен 16, 11:32    [19676578]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
db2top
MIRRORLOGPATH это зеркало для АКТИВНЫХ логов
Чтобы откладывать АРХИВНЫЕ логи на NFS-шару нужно использовать LOGARCHMETH1/2


Точно ведь, большое спасибо! не ожидал .... хотя в доке это описано

А зачем оно надо?
Часто активные логи лежат в файловой системе отличной от той, в которой база?
Дублирование ведь обычно делается в дисковых массивах, ZFS vdevs и т.п.

Тогда почему бы уж не дублировать и каталог с базой тоже ? :)
17 сен 16, 11:32    [19676579]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4876
dbtwoshnick,

Вы неправильно используете операции со снепшотами.
Про mirrorlogpath вам уже сказали. Для инициализации копии надо пользоваться db2inidb в нужном режиме, как написано по ссылке, которую я привел.
17 сен 16, 11:33    [19676580]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
db2top
100GB за 5 часов это очень плохо.
Из собственного недавнего: тестовая база в 1.3 TB ресторилась за 6 часов с TSM'а (некомпрессный бекап с LTO-6 ленты) и 4 часа с компрессного бекапа на NFS-шаре сервера с резервной площадки. В обоих случая по обе стороны гигабитные линки.


TSM где то в другой стойке до которой путь через свич в другой серверной ...

На локальный NFS сервер с гигабитным линком OFFLINE бэкап проходит за 1 час, ONLINE за полтора без нагрузки пользователй, с пользователями наверно подольше

НО! ...зачем тратить все эти часы на восстановление?! если:

1) основное хранилище со снэпшотами живо (т.е. бэкап с другого хранилища в этот момент времени НЕ нужен)
2) ZFS снэпшот позволяет проделать откат за 10 минут (включая db2 restart)

время некуда потратить чтоли?
17 сен 16, 11:37    [19676581]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
Mark Barinstein
dbtwoshnick,

Вы неправильно используете операции со снепшотами.
Про mirrorlogpath вам уже сказали. Для инициализации копии надо пользоваться db2inidb в нужном режиме, как написано по ссылке, которую я привел.


а в чем разница с точки зрения результата?
если можно, пожалуйста подробнее

просто мне так удобнее, как я использую

DB2 оказывается в состоянии как будто выключили сервер, но при этом заране сбросили все буфера и заморозили все IOP операции
т.е. режим безопасный

мне ненужна копия базы из снэпшота, мне просто нужен 100% работающий crash recovery без затрат моего времени на дополнительные манипуляции с командами db2 в области снятия снэпшотов для копий базы, перекаталогизации и т.п.
17 сен 16, 11:42    [19676585]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4876
автор
Не пойму, вы говорите о восстановлении которое состоит и из отката на снэпшот и одновременно о докате логов

Разве логи можно докатывать в любой момент отличный от "после db2 restore"?

Т.е. ну откатился я на снэпшот, зачем мне удалять активные логи? я ведь все равно не смогу сделать rollforward? максумум, что в данном случае возможно по логам - это crash recovery после команду restart db with write resume, или я ошибаюсь?
и как раз тут важно сохранить старые активные логи из снэпшота и чтобы DB2 не лез за архивными логами куда-то за пределы снэпшота или я не прав?
Вы ошибаетесь.
Мы не говорим здесь про db2 restore. Речь про откат на снепшот.
Вся эта тема с write suspend / db2inidb для того и затеяна, чтобы позволять такие вещи. Никаких restart database делать не надо.

Почему надо стирать старые архивные логи при db2inidb отличном от snapshot.
Логи с этими именами, скорее всего, уже сархивированы после write resume. И они содержат транзакции, по которым должен пойти rollforward. Именно они должны быть доступными rollforward, а не эти старые активные, до которых rollforward доберётся в первую очередь.
17 сен 16, 11:46    [19676589]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
забыл упомянуть, что снэпшотится весь каталог /home, включая /home/db2inst со всеми настройками DB2

т.е. у меня была задача перед созданием ZFS снэпшота привести данные базы в файловой системе в максимально консистентный вид, чтобы crash recovery после отката на этот снэпшот проходил всегда успешно

т.е. DB2 (СУБД) никогда даже и не узнает, что был снэпшот
17 сен 16, 11:48    [19676592]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
вернее, что был откат на снэпшот
17 сен 16, 11:48    [19676593]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
и снэпшот затевался именно как контрольная точка перед запуском скриптов,
т.е. активных транзакций в этот момент времени скорее всего не будет,
можно предварительно делать db2 force application all

это для для защиты от сбоем комплекса, а для защиты от багов разработчика или собственных ошибок при запуске скриптов
17 сен 16, 11:53    [19676601]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
dbtwoshnick
это НЕ для защиты от сбоев комплекса, а для защиты от багов разработчика или собственных ошибок при запуске скриптов
17 сен 16, 11:53    [19676604]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
можно было бы даже и db2stop делать до снэпшота,
но тогда сбрасываюся буфера - а это опять потеря времени на их повторный прогрев
17 сен 16, 11:55    [19676609]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4876
dbtwoshnick
Mark Barinstein
dbtwoshnick,

Вы неправильно используете операции со снепшотами.
Про mirrorlogpath вам уже сказали. Для инициализации копии надо пользоваться db2inidb в нужном режиме, как написано по ссылке, которую я привел.


а в чем разница с точки зрения результата?
если можно, пожалуйста подробнее

просто мне так удобнее, как я использую

DB2 оказывается в состоянии как будто выключили сервер, но при этом заране сбросили все буфера и заморозили все IOP операции
т.е. режим безопасный

мне ненужна копия базы из снэпшота, мне просто нужен 100% работающий crash recovery без затрат моего времени на дополнительные манипуляции с командами db2 в области снятия снэпшотов для копий базы, перекаталогизации и т.п.
В чем разница между выходом из квартиры через дверь, как положено, или через окно? В принципе, результат одинаковый - вы оказываетесь на улице.
Если вам удобнее выходить через окно - выходите. Только не спрашивайте потом, почему я падаю иногда, пачкаюсь, и как этот процесс выхода через окно оптимизировать.

Получение 100% работающего crash recovery - это самоцель?
Если цель - получить 100% работающую базу, то пользуйтесь db2inidb mydb as snapshot. Всего одна команда. Команда должна завершиться быстрее, т.к. в отичие от crash recovery, она просто откатывает все незавершенные транзакции. Ничего перекаталогизировать не надо, т.к. база уже каталогизирована на этой системе.
17 сен 16, 12:36    [19676661]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
Mark Barinstein
dbtwoshnick,
Вы как-то странно пытаетесь восстанавливать копии.
Почему вы не пользуетесь db2inidb?


мне не нужен клон или standby, на который бы я накатывал логи, и вообще мне не надо накатывать логи после отката на снэпшот, потому что подразумевается, что нужных транзакций, которые бы я хотел накатить после отката на ZFS снэпшот нет,
потому что перед запуском скрипта разработчиков, я бы остановил приложение, сделал application force all

судя по описанию:
http://www.ibm.com/support/knowledgecenter/SSEPGG_9.7.0/com.ibm.db2.luw.admin.cmd.doc/doc/r0004473.html
предположительно мне подошел бы режим MIRROR
т.е. db2inidb DBName AS MIRROR

но я не пойму, зачем мне это? что мне это даст по сравнению c restart db
restart db with write resume делаю лишь потому, что просто соnnect однажды не сработал и мне пришлось гуглить эту волшебную комбинацию :) restart db with write resume, чтобы потом начал работать connect

Mark Barinstein
dbtwoshnick,
Если вы хотите вернуться на копию базы, то вам после восстановления датасета достаточно сделать
db2inidb mydb as snapshot


мне нужно следующее:
допустим, я отключил всех пользователей и приложения, активных транзакций нет
нужно запустить скрипт от разработчиков или установить новую версию (обновить структуру базы), и если что-то пойдет не так, я не хочу связываться с долгим восстановлением из бэкапа с накатом логов, а хочу быстренько откатиться на снэпшот, чтобы повторить запуск скрипта с какими-то коррективами, может другими параметрами и т.п.

в доке написано, что db2inidb mydb as snapshot создает клон базы, что это такое клон ? где про это можно прочитать подробнее?

дока
Attempting to connect to a split mirror database before initializing it erases the log files needed during roll forward recovery.

мне не нужен rollforward recovery на точку позднее, чем был сделан снэпшот, т.е. активные логи из снэпшота, которые перейдут в архив меня полностью устроят

может быть есть книжки, где это все подробнее описано?
17 сен 16, 12:51    [19676673]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
Mark Barinstein
Если цель - получить 100% работающую базу

Именно так, причем чем быстрее, тем лучше

Mark Barinstein
, то пользуйтесь db2inidb mydb as snapshot. Всего одна команда.


Интересно конечно сравнили :) ярко. Уже понял, что принято через db2inidb mydb as snapshot, но в связи с относительной редкостью использования этого режима деталей гуглится про него немного для более лучшего понимания, а про restart db написано намного больше.

Хотелось бы узнать отличия между:

db2inidb mydb as snapshot
и
db restart write resume (- это crash recovery?)

Именно в терминах DB2 без бытовых аналогий, чтобы лучше понять, что там происходит в недрах DB2 в этих режимах


Mark Barinstein
Команда должна завершиться быстрее, т.к. в отичие от crash recovery, она просто откатывает все незавершенные транзакции.


Вот это уже очень интересно. Пожалуйста, объясните:

1) что делает crash recovery (restart db) кроме того, что делает db2inidb?
2) что делает db2inidb, чего не делает restart db?

Страшновато использовать команды без понимания, restart db хоть и медленнее, но пока что для меня она понятнее.
17 сен 16, 13:10    [19676699]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
Надо было выбрать ник dbtwoshnick-nooby :)

Чем больше читаешь про DB2, тем больше понимаешь, как мало знаешь про DB2.
17 сен 16, 13:13    [19676704]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4876
dbtwoshnick,

Клон == снэпшот == копия.
Вам нужен снэпшот.

db2inidb ничего сама не клонирует / копирует / создает.
Она инициализирует то, что находится на диске, в одном из 3-х нужных режимов. Выделенное слово - ключевое.

Т.е. вот вам надо вернуться к копии. Вы делаете db2stop, вернули состояние файловых систем DB2 в то состояние, в котором они были в момент write resume, db2start.
Дальше у вас есть выбор в зависимости от того, что вы хотите делать дальше.

- Если вам нужна копия (клон) базы, т.е. вы не хотите дальше накатываться по логам, то вы инициализируете базу as snapshot.
В этом случае оно откатывает все незавершенные транзакции в базе, если они там вообще были на момент write suspend, и открывает базу для работы. Вы получаете копию базы. Если вы находитесь в режиме архивирования логов, то начинается новая логовая последовательность.
- Если вы решили накатываться по логам, которые появились после write resume, то вы инициализируете базу as mirror. Дальше вы накатываете базу по этим логам так же, как вы бы делали после db2 restore из онлайн архива. Эти появившиеся логи, естественно, должны быть доступны rollforward.
- Если вы решили сделать standby базу (например, для HADR), то вы инициализируете ее в режиме as standby. Дальше вы вы обращаетесь с этой базой так же, как вы бы делали после db2 restore на standby для настройки DB2 HADR.

Всё это описано в документации по ссылке выше.
17 сен 16, 13:29    [19676723]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
Mark Barinstein
- Если вам нужна копия (клон) базы, т.е. вы не хотите дальше накатываться по логам, то вы инициализируете базу as snapshot.
В этом случае оно откатывает все незавершенные транзакции в базе, если они там вообще были на момент write suspend, и открывает базу для работы. Вы получаете копию базы. Если вы находитесь в режиме архивирования логов, то начинается новая логовая последовательность.
- Если вы решили накатываться по логам, которые появились после write resume, то вы инициализируете базу as mirror. Дальше вы накатываете базу по этим логам так же, как вы бы делали после db2 restore из онлайн архива. Эти появившиеся логи, естественно, должны быть доступны rollforward.
- Если вы решили сделать standby базу (например, для HADR), то вы инициализируете ее в режиме as standby. Дальше вы вы обращаетесь с этой базой так же, как вы бы делали после db2 restore на standby для настройки DB2 HADR.


на первый взгляд из трех вариантов этого описания действительно as snapshot выглядит наиболее подходящим

но смущает слово "копия", по идее копия (по сравнению с оригиналом) может получить какие-то новые идентификаторы чего-либо, на то она и копия, а не оригинал

поэтому с моей точки зрения (пока), было бы логичнее (в моем понимании), но не удобнее и не быстрее
использовать mirror, но с модификатором without rolling forward, если бы так было можно
как мне кажется, это было бы больше похоже на
db2stop; zfs snapshot; db2start,
а потом db2stop; zfs rollback; db2start

т.е. при этом не создавалось бы никаких копий, а оставался бы только оригинал, как он был в момент снэпшота
17 сен 16, 13:48    [19676756]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4876
dbtwoshnick
Хотелось бы узнать отличия между:

db2inidb mydb as snapshot
и
db restart write resume (- это crash recovery?)

Именно в терминах DB2 без бытовых аналогий, чтобы лучше понять, что там происходит в недрах DB2 в этих режимах
db2 restart db применяется, как написано в документации, когда обслуживание базы завершилось неожиданно. Но это не ваш случай - write suspend - вполне себе ожидаемая операция. То, что оно в вашем случае работает - удачное недокументированное стечение обстоятельств, которое может работать до поры до времени. Если вы встретитесь в дальнейшем с проблемами - первое, что вам скажут - не делайте так больше.
dbtwoshnick
Вот это уже очень интересно. Пожалуйста, объясните:

1) что делает crash recovery (restart db) кроме того, что делает db2inidb?
2) что делает db2inidb, чего не делает restart db?

Страшновато использовать команды без понимания, restart db хоть и медленнее, но пока что для меня она понятнее.
crash recovery состоит из 2-х последовательных фаз: forward и backward recovery.
Forward - в файлы с данными записываются подтвержденные изменения, найденные в логах, которые не успели из буферов сброситься на диск.
Backward - откатываются изменения, сделанные незавершенными транзакциями.

Про db2inidb в доке сказано, что она только откатывает незавершенные транзакции (т.е. выполняет только backward фазу, как можно понять), но, честно говоря, мне кажется, что forward фаза всё равно нужна и в этом случае. Поэтому, скорее всего, обе они в этом смысле должны делать то же самое.
Разница может быть в том, что db2inidb делает какие-то нужные внутренние операции при инициализации (флаги в котрольных файлах), которые crash recovery не делает и наоборот.

Для ускорения forward фазы можете перед write resume пользоваться командой flush bufferpools all - это сброс "грязных" страниц из памяти на диск. Forward фазе после этого надо будет мешьше работы делать.
17 сен 16, 13:48    [19676757]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
Mark Barinstein
Разница может быть в том, что db2inidb делает какие-то нужные внутренние операции при инициализации (флаги в котрольных файлах), которые crash recovery не делает и наоборот.


вот это меня больше всего и смущает, пометит базу какой-нибудь копией вместо оригинала, а потом какие-нибудь операции не пойдут, например с CDC агентом и придется все перенастривать или вообще из бэкапа базу восстанавливать ...
17 сен 16, 13:57    [19676771]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
Mark Barinstein
db2 restart db применяется, как написано в документации, когда обслуживание базы завершилось неожиданно. Но это не ваш случай - write suspend - вполне себе ожидаемая операция.


Это был бы не мой случай, если бы я следовал логике inidb.
http://www.ibm.com/support/knowledgecenter/SSEPGG_9.7.0/com.ibm.db2.luw.admin.cmd.doc/doc/r0001974.html

дока
WRITE RESUME
Allows you to force a database restart on databases that failed while I/O writes were suspended. Before performing crash recovery, this option will resume I/O writes by removing the SUSPEND_WRITE state from every table space in the database.

Но если представить, что неожиданно скрипт разработчика отработал неправильно и мне неожиданно захотелось остаться в сотоянии снэпшота после write suspend, а для этого не стал запускать скрипт разработчика (как будто заранее предчувствовал проблему), а вместо этого просто выдернул вилку сервера из розетки сразу же после write suspend, ну еще zfs снэпшот сделал к которому откатился на всякий случай после повторного включения :) так можно представить?


дока
The WRITE RESUME option can also be used in the case where the connection used to suspend I/O writes is currently hung and all subsequent connection attempts are also hanging. When used in this circumstance, RESTART DATABASE will resume I/O writes to the database without performing crash recovery.

А как DB2 определит был "IO connection hung" или во время write suspend я выдернул вилку сервера из розетки или восстановился из снэпшота и потом запустил DB2?

дока
RESTART DATABASE with the WRITE RESUME option will only perform crash recovery when you use it after a database crash. The WRITE RESUME parameter can only be applied to the primary database.

мне и надо primary

Mark Barinstein
То, что оно в вашем случае работает - удачное недокументированное стечение обстоятельств, которое может работать до поры до времени.

Не представляю как может быть иначе, если я не планировал изначально вообще использовать write suspend, а просто хотел воспользоваться функционалом crash recovery, но при этом создать максимально благоприятные условия для recovery. т.е. сбросить все данные из различных write cash (DB2, ext3->iSCSI, ZFS zvol) на диск и только потом снэпшотнуть (выдернуть вилку из розетки), а потом воспользоваться описанием restart db write resume про неожиданные ситуации, которую по сути я сам вызвал. Про write suspend уже потом узнал случайно, очень пригодилось тем, что именно в доке по команде restart db write resume описана неожиданная ситуация, которую я эксплуатирию в своем решении.
17 сен 16, 14:15    [19676806]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4876
dbtwoshnick
Mark Barinstein
Разница может быть в том, что db2inidb делает какие-то нужные внутренние операции при инициализации (флаги в котрольных файлах), которые crash recovery не делает и наоборот.


вот это меня больше всего и смущает, пометит базу какой-нибудь копией вместо оригинала, а потом какие-нибудь операции не пойдут, например с CDC агентом и придется все перенастривать или вообще из бэкапа базу восстанавливать ...
Нет никакой разницы между:
db2inidb mydb as snapshot
и
db2inidb mydb as mirror
db2 rollforward db mydb stop

Ничем таким база не метится специально.
CDC агент не должен испугаться.
17 сен 16, 14:19    [19676814]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4876
dbtwoshnick,

restart db write resume вы используете только в том случае, когда вы сделали write suspend, и после этого база упала по какой-то причине, не долждавшись онончания копирования и write resume.
В остальных случаях эту команду использовать не надо, и то, что вы используете эту команду после восстановления нормально завершившегося снэпшота - тоже неправильно.
17 сен 16, 14:27    [19676825]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
Mark Barinstein
dbtwoshnick,
restart db write resume вы используете только в том случае, когда вы сделали write suspend, и после этого база упала по какой-то причине, не долждавшись онончания копирования и write resume.

А разве состояние в снэпшоте, перед которым были сброшены на диск все write cache какие только можно представить, может быть менее приемлемым для recovery, чем если бы база действительно упала?

Mark Barinstein
В остальных случаях эту команду использовать не надо

Вот я пытаюсь понять почему не надо, какие могут быть побочные эффекты?

Mark Barinstein
и то, что вы используете эту команду после восстановления нормально завершившегося снэпшота - тоже неправильно.

Хуже то ведь не будет, разве запрещено запускать restart database (без write resume) на исправных базах в обычном не suspend состоянии?
write resume лишь гарантированно выводит базу из этого состояния
и заметьте, что снэпшот охватывает полностью весь /home/db2inst без бинарников /opt конечно же

Т.е. у DB2 нет шансов определить, что это было, падение или восстановление из снэпшота, не так ли?

Мне кажется, пока IBM или кто-нибудь другой не напишет детально явные причины по которым нельзя, то мне не понять этого...

Вот представьте, что мы вообще забыли про write suspend и просто думаем, как бы нам снять снэпшот из которого база гарантированно прийдет в норму, откат транзакций разрешен.

Ведь если crash recovery рассчитан даже на сложные условия IO, когда может отвалиться хранилище и часть данных вообще останется в RAM и потеряется там.

А у меня сброс всех write cache на диск - т.е. тепличные условия для recovery.

Я не пытаюсь вас переспорить или кому-либо навязать свою точку зрения, возможно даже пытаюсь опровергнуть свою точку зрения на этот вопрос.

Вот представьте, мы не делаем никакого снэпшота, делаем только write suspend и потом write resume, это ведь разрешено

Теперь представьте мы добавили между suspend и resume snapshot.

Откатились, как DB2 догадается был ли откат на снэпшот или включение после сбоя? Кааак?!
17 сен 16, 14:52    [19676876]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4876
dbtwoshnick,

Мы можем долго еще дискутировать на эту тему.
db2 - довольно сложный продукт, и никто не будет вам писать объяснений, почему определенный процесс надо делать именно так, как описано, а не по-другому, даже если очень хочется, и вроде бы работает.
Почему для останова db2 по-хорошему надо пользоваться db2stop force, а не, скажем, kill -9. Ведь восстановится, crash recovery есть.
Моя позиция по любому процессу такая - если есть штатная процедура, надо ее использовать, а не искать себе приключений.
17 сен 16, 15:15    [19676905]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
Mark Barinstein
Для ускорения forward фазы можете перед write resume пользоваться командой flush bufferpools all - это сброс "грязных" страниц из памяти на диск.


эта команда поддерживается в v9.7?
почему-то выдает SQL0104N :(


в v10 работает
17 сен 16, 15:24    [19676926]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
Mark Barinstein
dbtwoshnick,

Мы можем долго еще дискутировать на эту тему.
db2 - довольно сложный продукт, и никто не будет вам писать объяснений, почему определенный процесс надо делать именно так, как описано, а не по-другому, даже если очень хочется, и вроде бы работает.
Почему для останова db2 по-хорошему надо пользоваться db2stop force, а не, скажем, kill -9. Ведь восстановится, crash recovery есть.
Моя позиция по любому процессу такая - если есть штатная процедура, надо ее использовать, а не искать себе приключений.


Ваша позиция понятна, но я именно на данный вопрос смотрю с точки зрения разрешено то, что не запрещено, и этим надо пользоваться, если это приносит пользу.

Если бы можно было еще подробнее ознакомиться с более детальным описанием inidb as snapshot, возможно я бы начал ее использовать, а пока restart db мне кажется безопаснее применительно конкретно к моему случаю.

За ваши исчерпывающие ответы и советы ОГРОМНОЕ СПАСИБО! Ни раз уже выручали, просто я больше читаю, чем пишу в форум.
17 сен 16, 15:30    [19676941]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
db2 connect to DBName

потом

[db2inst@XXX ~]$ db2 "FLUSH BUFFERPOOLS ALL"

в результате:

DB21034E The command was processed as an SQL statement because it was not a
valid Command Line Processor command. During SQL processing it returned:
SQL0104N An unexpected token "END-OF-STATEMENT" was found following "FLUSH
BUFFERPOOLS". Expected tokens may include: "JOIN <joined_table>".
SQLSTATE=42601
17 сен 16, 15:42    [19676951]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4876
dbtwoshnick,

Замена FLUSH BUFFERPOOLS ALL для некоторых версий до 10.1:
db2pdcfg -flushbp

Чтоб посмотреть, какой это оказывает эффект, запустите до и после:
db2pd -db mydb -dirtypages summary | awk -v RS='\n\n' '{if ($0 ~ /pages %/) print $0;}'
17 сен 16, 15:47    [19676961]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
db2top
Guest
dbtwoshnick
А зачем оно надо?

Для пущей отказоустойчивости
dbtwoshnick
Часто активные логи лежат в файловой системе отличной от той, в которой база?

В критичных и нагруженных продакшенах обычно всегда. Причем на отдельных raid-группах.
dbtwoshnick
Дублирование ведь обычно делается в дисковых массивах, ZFS vdevs и т.п.
Тогда почему бы уж не дублировать и каталог с базой тоже ? :)

Шит, как говорится, хаппенс. Падают (крайне редко конечно) даже отказоустойчивые CХД. Так что некоторые параноики бывает диски с разных стороджей LVM-ом зеркалируют.
17 сен 16, 16:24    [19677024]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
db2top
Шит, как говорится, хаппенс. Падают (крайне редко конечно) даже отказоустойчивые CХД. Так что некоторые параноики бывает диски с разных стороджей LVM-ом зеркалируют.


а если LVM бахнется ? :)

не проще сделать тройные зеркала в аппаратном массиве RAID10 или zmirror3?
17 сен 16, 16:44    [19677067]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
или у них даже отдельные линии связи да еще и с бондингом нескольких каналов до каждого хранилища в LVM?
но тогда отказоустойчивость железки, на которой крутится DB2 с LVM должна быть выше всех стораджей и линков до них
это из той области, когда можно и процы и оперативку на ходу менять?

наверно, это отдельное направление по обеспечению повышенной отказоустойчивости (выше средней)
за каждый 1% повышения отказоустойчивости, наверно, цена решения увеличивается на много процентов?
17 сен 16, 17:42    [19677173]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
db2top
В критичных и нагруженных продакшенах обычно всегда. Причем на отдельных raid-группах.


Интересно, если отдельные части базы разбросаны по разным ZFS датасетам
то можно ли использовать для снэпшотов способ, похожий на мой (т.е. описанный выше), хотя бы с inidb в случае отката на снэпшотЫ?

Т.е. например, база на одном датасете, зеркало активных логов на другом, возможно еще какие-то файлы (а вот ктстати, например, logarchmeth1) на третьем датасете.


1) Уводим базу в suspend

2) Далее снэпшотим каждый из датасетов (которые могут быть даже в разных пулах на разных хранилищах) по отдельности для удобства с одинаковым именем снэпшота

3) И потом возвращаем базу обратно в состояние resume

Почему-то сразу не подумал о такой возможности, тогда ZFS снэпшоты подойдут даже при масштабировании?

Ведь в состоянии suspend нет никакой необходимости снэпшотить все датасеты абсолютно синхронно (да это и невозможно), главное успеть везде отснэпшотиться до resume, т.е. suspend-resume позволяет растянуть промежуток времени для "синхронизации" снэпшотов на разных хранилищах до любого приемлемого значения, наверно suspend для этого в первую очередь и присутствует в DB2?

В моем относительно простом случае можно было бы, наверно, даже снимать снэпшот прямо на ходу, на тестовой базе пробовал несколько раз такое, crash recovery отрабатывает без проблем, только дольше.
17 сен 16, 19:49    [19677439]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
Mark Barinstein
dbtwoshnick,

Замена FLUSH BUFFERPOOLS ALL для некоторых версий до 10.1:
db2pdcfg -flushbp

Чтоб посмотреть, какой это оказывает эффект, запустите до и после:
db2pd -db mydb -dirtypages summary | awk -v RS='\n\n' '{if ($0 ~ /pages %/) print $0;}'


Марк,

можно ли это команду синхронизировать с шелом из которого она запускается?

пока получается асинхронно:

++ db2pdcfg -flushbp
State of the bufferpools:
Oldest LSN: 00000281FCE0902C
Newest LSN: 0000028275F9DCD4
Initiating background flush.
You can use "db2pdcfg -flushbp q" to monitor the progress of the flush operation.
When the oldest LSN reported by the q option is greater than the
newest LSN reported during the initial flush, then the flush has completed.
18 сен 16, 11:12    [19678903]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4876
dbtwoshnick
можно ли это команду синхронизировать с шелом из которого она запускается?

пока получается асинхронно:

++ db2pdcfg -flushbp
State of the bufferpools:
Oldest LSN: 00000281FCE0902C
Newest LSN: 0000028275F9DCD4
Initiating background flush.
You can use "db2pdcfg -flushbp q" to monitor the progress of the flush operation.
When the oldest LSN reported by the q option is greater than the
newest LSN reported during the initial flush, then the flush has completed.

Можно, конечно, тут в выводе команды даже написано как.
При первом вызове (без q) запоминаете newest lsn.
Последующие вызовы делаете с q в цикле с некоторой паузой после каждого до тех пор, пока при очередном вызове oldest lsn не будет больше, чем запомненный на первом шаге. Или до тех пор, пока не истечёт некоторый допустимый промежуток времени.
Это легко реализуется в командном файле.
18 сен 16, 15:12    [19679348]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
Я имел ввиду, нет ли готового ключа, отслеживать конечно можно и самостоятельно, но проще, наверно, поставить паузу несколько секунд после сброса буферов.

Вообще после MSSQL 2005/2008 с моей точки зрения DB2 v8 напоминал некий конструктор (очень мощный), но который надо было тщательно настраивать вручную и обвешивать различными скриптами, т.е. велосипедить и читать много буков в доке :)

В современных версиях DB2 конечно многое улучшено, более удобно и упрощено для админа,
но лет 10 назад, как мне кажется MSSQL был явно удобнее, если админить DB2 без кучи готовых custom скриптов и опытным спеца-консультанта.

Хотя наверно у них была разная целевая аудитория, т.е. предполагаемая нагрузка на СУБД, требования по надежности и т.п.?

Интересно, усилится ли конкуренция после выхода MSSQL под Linux и увидем ли мы переход части платного функционала в бесплатный Express C?
18 сен 16, 15:52    [19679399]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
Mark Barinstein
dbtwoshnick
пропущено...


вот это меня больше всего и смущает, пометит базу какой-нибудь копией вместо оригинала, а потом какие-нибудь операции не пойдут, например с CDC агентом и придется все перенастривать или вообще из бэкапа базу восстанавливать ...
Нет никакой разницы между:
db2inidb mydb as snapshot
и
db2inidb mydb as mirror
db2 rollforward db mydb stop

Ничем таким база не метится специально.
CDC агент не должен испугаться.



Команда 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? и не только?

Что удивительно, такая замечательная фича как write suspend существовала в DB2 более 10 лет назад!
К сожалению нищеброды типа меня воспользоваться ей не могли в силу ограниченного доступа к Solaris в те времена.
Я даже пропустил фазу появления ZFS в kFreeBSD :(
Начал пользоваться только в 2012 при появлении чего-то более менее стабильного для Linux ядра.
22 сен 16, 13:42    [19696443]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
Гуглю про файлы базы DB2 в разных хранилищах, можно ли безопасно снэпшотить после write suspend?

https://www.ibm.com/support/knowledgecenter/SSGLW6_5.2.0/com.ibm.p8.common.admin.doc/backup_restore/backup_online_technologies.htm
Storage vendors provide snapshot capabilities that span multiple data volumes and logical unit numbers (LUNs) by using consistency groups, also known as protection groups. With these capabilities, they can capture a snapshot very quickly (almost instantaneously) across multiple data volumes or LUNs. This is a key technology for enabling online backups because it preserves relationships and references between data sets. It is also important to create the snapshots rapidly in order to both minimize the impact on the system and its users and to ensure that the data is consistent across data sets.


т.е. надо какие-то "protection groups" ?
22 сен 16, 13:46    [19696460]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
очень хотелось бы вынести активные логи на Intel Pro DC 3700 nvram

мне кажется производительность должна вырасти и очень даже заметно, но все уперлось в снэпшоты
22 сен 16, 14:04    [19696576]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
https://www.ibm.com/support/knowledgecenter/SSGLW6_5.2.0/com.ibm.p8.common.admin.doc/backup_restore/backup_online_technologies.htm

Suspending database writes reduces the overall rate of change of the data and places the database in a relatively clean state, which improves the chances of capturing all the data sets in a consistent state, even if the snapshot operation is not perfectly aligned in time across all the data sets.


получается таки можно снэпшотить базы, отдельные части которых находятся на разных ZFS DataSet?

и синхронизация по времени не нужна, смущает только фраза про шансы получения консистентной базы,

но наверно предполагается не всегда возможное получение консистентной СРАЗУ со снэпшота

но после crash recovery всегда?
22 сен 16, 14:21    [19696705]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
сделаю закладочку:

http://www.dbforums.com/showthread.php?1642266-Write-Suspend-and-commit
22 сен 16, 14:53    [19696877]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
И еще вопросы:

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 сен 16, 16:37    [19697476]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4876
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? и не только?

t log(n), log(n+1), log(n+2)
---+--------------------------->
| log(n), log(n+1)
+------------------>

Вот у вас жила себе база, в момент t вы сделали ее копию, у вас стали плодиться логи в верхней последовательности.
Потом вы решили вернуться на копию, восстановили базу на момент времени t, но по верхней последовательности логов накатываться не стали. Это ключевой момент. Не важно, как именно вы это сделали: с помощью crash recovery, db2inidb as snapshot, db2inidb as mirror/standby + db2 rollforward stop.
Базу после этого открыли, она начала генерировать логи с теми же самыми номерами, но в нижней последовательности. Эти логи уже друг с другом не совместимы, это две абсолютно 2 разные цепочки логов.
22 сен 16, 23:21    [19698641]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
Мне все же кажется, что без write suspend надо сначала снэпшотить активые логи, а потом базу,
потому что тогда возможно часть инфы продублируется в базе и логах и потом при последующем crash recovery DB2 заметит это и примет какое-либо правильное решение по этому поводу, позволяющее успешно восстановить базу.

А что будет при откате, если сделать наоборот, сначала снэпшотить базу, а потом активные логи?

База окажется в состоянии до момента времени, отраженного в самом начале активного лога, т.е. часть инфы будет утеряна, и если DB2 хотя бы заметит это, то наверно в лучшем случае откажется стартовать базу?

Все же должны же быть какие то мысли у специалистов по этому поводу, в т.ч. на базе официальной доки?

Ведь не исключено без всяких снэпшотов падение нескольких хранилищ почти одновременно, но все же с рассинхронизацией по времени, и наверняка crash recovery рассчитан и на такой случай?

Понятно, что еще остается и опция восстановления из бэкапа с архивными логами в случае, если crash recovery не справится со сложившейся ситуацией в базе.
24 сен 16, 09:38    [19703712]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
может быть, кому-нибудь интересно, получился такой скрипт снэпшотинга:

set -x;

SnapshotSuffix=$1;

suspend_db()
{
        Name=$1;
        Sleep=$2;

        echo "===== Suspending database $Name";
        db2 terminate;
        db2 connect to $Name;
        db2pdcfg -flushbp; sleep $Sleep"s";

#       db2 flush bufferpools all;

        db2 set write suspend for database;
        Result=$?;

        db2pdcfg -flushbp q;
#       db2 disconnect $Name;
        echo;

        return $Result;
}

resume_db()
{
        Name=$1;
                                                                                                                                                                                                                                            
        echo "===== Resuming database $Name";                                                                                                                                                                                               
                                                                                                                                                                                                                                            
        db2 terminate;                                                                                                                                                                                                                      
        db2 connect to $Name;                                                                                                                                                                                                               
                                                                                                                                                                                                                                            
        db2 set write resume for database;                                                                                                                                                                                                  
        Result=$?;                                                                                                                                                                                                                          
                                                                                                                                                                                                                                            
#       db2 disconnect $Name;                                                                                                                                                                                                               
        echo;                                                                                                                                                                                                                               
                                                                                                                                                                                                                                            
        return $Result;                                                                                                                                                                                                                     
}                                                                                                                                                                                                                                           
                                                                                                                                                                                                                                            
zfs_snapshot()                                                                                                                                                                                                                              
{                                                                                                                                                                                                                                           
        FullSnapName=$1;                                                                                                                                                                                                                    
                                                                                                                                                                                                                                            
        timeout 30s ssh z1 "/xxx/create_snapshot2.sh $FullSnapName";                                                                                                                                                             
        Result=$?;                                                                                                                                                                                                                          
                                                                                                                                                                                                                                            
        return $Result;
}


db2 archive log for db Base3;
db2 archive log for db Base2;
db2 archive log for db Base1;

if (suspend_db Base1 5) && (suspend_db Base2 1) && (suspend_db Base3 2); then
{
        SuspendResult="safe_suspended";
} 
else
{
        SuspendResult="___WARNING_UNSAFE___NOT_suspended___";
} fi;

/xxx/flush.sh;

SnapName=$(date +\%Y_\%m_\%d__\%H_\%M_\%S)_$SuspendResult"_$SnapshotSuffix";

zfs_snapshot "nvram/xxx-temp@$SnapName";
SnapshotResult1=$?;

zfs_snapshot "data/xxx-database2@$SnapName";
SnapshotResult2=$?;

SnapshotResult3=0;


resume_db Base3;
resume_db Base2;
resume_db Base1;

timeout 5m /utils/backup/xxx_log.sh;
timeout 30s ssh backup2 "/xxx/create_snapshot.sh data/backup/xxx-log $SnapName; sync";

echo `date` >> /download/snapshot_log.txt;

if [ $SnapshotResult1 == 0 ] && [ $SnapshotResult2 == 0 ] && [ $SnapshotResult3 == 0 ]; then
{
        if [ "$SuspendResult" == "safe_suspended" ]; then
        {
                echo "============ SUCCESSFUL SUSPEND & SNAPSHOT.";
                exit 0;
        }
        else
        {
                echo "============ ERROR: BAD SUSPEND! but a SNAPSHOT CREATED ...";
                exit 1;
        } fi;
}
else
{
        echo "============== ERROR: COULD NOT CREATE SNAPSHOTS! SUSPEND STATUS was: $SuspendResult";
        exit 2;
} fi;

exit 3; # shall not reach here!
27 сен 16, 18:55    [19715189]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
Первый раз столкнулся с проблемой невозможности стартануть базу из снэпшота.

На тестовом сервере после репликации снэпшота с пром. сервера.

++ 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 окт 16, 09:54    [19797997]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
и как после этого разносить table spaces по разным хранилищам?

если нет возможности нормально сбросить все dirty pages


может быть, надо сначала сделать QUIESCE ? потом сброс буферов, и только потом снэпшот,

но ведь тогда все соединения будут потеряны?

дока
Forces all users off the specified instance and database and puts it into a quiesced mode.
19 окт 16, 09:58    [19798038]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
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 окт 16, 10:05    [19798103]     Ответить | Цитировать Сообщить модератору
 Re: Пожалуйста, посоветуйте, как можно архивировать логи в режиме LOGARCHMETH1 = LOGRETAIN  [new]
dbtwoshnick
Member

Откуда:
Сообщений: 160
когда все части базы находились в одном ZFS dataset такого никогда не было

вопрос, добиться корректного снэпшота?
19 окт 16, 17:07    [19800977]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2 3      [все]
Все форумы / IBM DB2, WebSphere, IMS, U2, etc Ответить