История изменений

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

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

Database crash recovery разве не должен нормально отработать с любого состояния, при условии, что все каталоги базы данных находятся на одном и том же ZVol, т.е. и данные и настройки, и логи, т.е. весь /home/db2inst на ZVol Нет обычного блочного устройства (не ZFS), состояние которого бы отличалось от состояние после отката ZFS. Кстати экспериментировал на тестовой базе, размещая логи на другом NFS маунте, и таки да, в таком случае база может не рестартануть, но у меня то все на одном и том же ZVol, который сначала откатывается к консистентному состоянию ZFS, а потом база откатывается к своему консистентному состоянию уже на этом ZVol

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

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

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

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

Database crash recovery разве не должен нормально отработать с любого состояния, при условии, что все каталоги базы данных находятся на одном и том же ZVol, т.е. и данные и настройки, и логи, т.е. весь /home/db2inst на ZVol Нет обычного блочного устройства (не ZFS), состояние которого бы отличалось от состояние после отката ZFS. Кстати экспериментировал на тестовой базе, размещая логи на другом NFS маунте, и таки да, в таком случае база может не рестартануть, но у меня то все на одном и том же ZVol, который сначала откатывается к консистентному состоянию ZFS, а потом база откатывается к своему консистентному состоянию уже на этом ZVol

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

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

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

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

Database crash recovery разве не должен нормально отработать с любого состояния, при условии, что все каталоги базы данных находятся на одном и том же ZVol, т.е. и данные и настройки, и логи, т.е. весь /home/db2inst на ZVol Нет обычного блочного устройства (не ZFS), состояние которого бы отличалось от состояние после отката ZFS. Кстати экспериментировал на тестевой базе, размещая логи на другом NFS маунте, и таки да, в таком случае база может не рестартануть, но у меня то все на одном и том же ZVol, который сначала откатывается к консистентному состоянию ZFS, а потом база откатывается к своему консистентному состоянию уже на этом ZVol

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

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

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

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

Database crash recovery разве не должен нормально отработать с любого состояния, при условии, что все каталоги базы данных находятся на одном и том же ZVol, т.е. и данные и настройки, и логи, т.е. весь /home/db2inst на ZVol Нет обычного блочного устройства (не ZFS), состояние которого бы отличалось от состояние после отката ZFS. Кстати экспериментировал на тестевой базе, размещая логи на другом NFS маунте, и таки да, в таком случае база может не рестартануть, но у меня то все на одном и том же ZVol, который сначала откатывается к консистентному состоянию ZFS, а потом база откатывается к своему консистентному состоянию уже на этом ZVol

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

ну и кроме того делаются ежечасные снэпшоты в состоянию write suspend, уж к ним то можно откатиться точно

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

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

Database crash recovery разве не должен нормально отработать с любого состояния, при условии, что все каталоги базы данных находятся на одном и том же ZVol, т.е. и данные и настройки, и логи, т.е. весь /home/db2inst на ZVol Нет обычного блочного устройства (не ZFS), состояние которого бы отличалось от состояние после отката ZFS. Кстати экспериментировал на тестевой базе, размещая логи на другом NFS маунте, и таки да, в таком случае база может не рестартануть, но у меня то все на одном и том же ZVol, который сначала откатывается к консистентному состоянию ZFS, а потом база откатывается к своему консистентному состоянию уже на этом ZVol

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

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

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

Database crash recovery разве не должен нормально отработать с любого состояния, при условии, что все каталоги базы данных находятся на одном и том же ZVol, т.е. и данные и настройки, и логи, т.е. весь /home/db2inst на ZVol

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

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

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

Database crash recovery разве не должен нормально отработать с любого состояния, при условии, что все каталоги базы данных находятся на одном и том же ZVol, т.е. и данные и настройки, и логи, т.е. весь /home/db2inst на ZVol

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

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

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

Database crash recovery разве не должен нормально отработать с любого состояния, при условии, что все каталоги базы данных находятся на одном и том же ZVol, т.е. и данные и настройки, и логи, т.е. весь /home/db2inst на ZVol