LINUX.ORG.RU

Не создавать tiny provisioning тома, не делать снапшотов. По умолчанию они и так не создаются, снапшоты автоматически тоже не делаются, так что COW не используется пока ты не задействуешь соответствующий функционал.

Jameson ★★★★★
()
Ответ на: комментарий от Jameson

Это понятно про блочные устройства.

Еще интересно в каком состоянии нынче dm-integrity, чтобы оно могло считать чексуммы как ZFS ?

https://forums.servethehome.com/index.php?threads/rhel-lvm-raid-does-have-bit...

sanyo1234
() автор топика
Ответ на: комментарий от sanyo1234

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

Если создавать снапшоты предполагается в целях резервного копирования — это не лучшая идея для СУБД, лучше на уровне самой базы это делать.

Jameson ★★★★★
()
Ответ на: комментарий от Jameson

Бэкапы понятно штатно надо делать.

Мне вообще хотелось бы узнать, как хотя бы проконтролировать текущее состояние LVM COW (включено или выключено), кроме как листануть снэпшоты?

sanyo1234
() автор топика
Ответ на: комментарий от sanyo1234

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

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

Я так понимаю, основная проблема, связанная с COW и отрицательно влияющая на производительность дисковой подсистемы, - это фрагментация?

Но если уж нужны снэпшоты с COW, то проще сразу взять ZFS.

sanyo1234
() автор топика
Последнее исправление: sanyo1234 (всего исправлений: 1)
Ответ на: комментарий от sanyo1234

Я не думаю что для этого есть какая то рукоятка или индикатор. Думаю что ситуация COW включен, но не работает аналогичен ситуации COW выключен. Если LVM не использует функционал при котором необходимо копировать при записи — он и не копирует. Ибо некуда. И незачем.

Jameson ★★★★★
()
Ответ на: комментарий от sanyo1234

так понимаю, основная проблема, связанная с COW и отрицательно влияющая на производительность дисковой подсистемы, - это фрагментация?

Да, но у LVM блоки достаточно крупные, будет «макрофрагментация», она не такая страшная как микро. Но да, при постоянном использовании снапшотов фрагментация будет нарастать.

Jameson ★★★★★
()
Ответ на: комментарий от Jameson

Хм, какой-то дефрагментатор даже есть:

https://bisqwit.iki.fi/source/lvm2defrag.html

Интересно, дефрагментация LVM возможна online?

IMHO в ZFS дефрагментация возможна только через send | receive ? Но почти online, т.е. можно добиться очень короткого downtime за счет нескольких итераций инкрементального копирования с уменьшающимся остатком.

sanyo1234
() автор топика
Ответ на: комментарий от sanyo1234

либо снэпшоты либо скорость работы

Снапшоты на LVM2 медленные. Больше пяти снапшотов мы вообще не делаем, потому что начинаются слишком заметные тормоза. Не для этого они.

Funny fact: в PVE вообще нет поддержки снапшотов на LVM2 — не стали делать за бесперспективностью этой идеи.

Но если уж нужны снэпшоты с COW, то проще сразу взять ZFS.

Да. Возьми сразу ZFS, серьёзно, мы так и сделали. Она рекордов скорости не ставит, но и в процессе работы не деградирует.

Aceler ★★★★★
()
Ответ на: комментарий от Aceler

Да. Возьми сразу ZFS, серьёзно, мы так и сделали.

Я тоже так делал.

Она рекордов скорости не ставит, но и в процессе работы не деградирует.

Увы ZFS за счет фрагментации деградирует и еще как, через несколько лет использования под интенсивной нагрузкой СУБД с рандомным доступом и со снэпшотами ессно, скорость чтения с zvol без L2ARC падает до 1-5 Мб/c.

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

sanyo1234
() автор топика
Последнее исправление: sanyo1234 (всего исправлений: 1)
Ответ на: комментарий от sanyo1234

Поступил ответ от эксперта по ZFS: все записи хранятся в виде отдельных COW транзакций даже в ZFS dataset без снэпшотов.

sanyo1234
() автор топика
Последнее исправление: sanyo1234 (всего исправлений: 1)
Ответ на: комментарий от Jameson

Если создавать снапшоты предполагается в целях резервного копирования — это не лучшая идея для СУБД, лучше на уровне самой базы это делать.

Почему не лучшая и чем лучше?

Вообще резервное копирование лучше всего делать на уровне архивации wal-логов. Но и снапшоты, имхо, хорошее решение.

vbr ★★★★
()
Ответ на: комментарий от vbr

Почему не лучшая и чем лучше?

Потому что в момент создания снапшота система не знает какие данные обрабатывает в памяти СУБД и база может быть неконсистентна в момент создания снапшота, если конечно не отправить команду CHEСKPOINT postgresql
https://postgrespro.ru/docs/postgresql/15/sql-checkpoint

Samamy ★★★
()
Последнее исправление: Samamy (всего исправлений: 1)
Ответ на: комментарий от Samamy

Ну неконсистентна и что? Последняя транзакция на диске будет. При старте отмотает куда надо.

Нежелательно копировать через cp -r и подобное, т.к. там данные копируются не одновременно и может действительно получиться плохой бэкап. Хотя по факту куча людей так делает. А снапшот такой проблемы лишён.

vbr ★★★★
()
Ответ на: комментарий от vbr

Вообще резервное копирование лучше всего делать на уровне архивации wal-логов. Но и снапшоты, имхо, хорошее решение.

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

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

Причем после отката на снэпшот можно накатить архивные логи до нужной точки.

sanyo1234
() автор топика
Ответ на: комментарий от vbr

Нежелательно копировать через cp -r и подобное, т.к. там данные копируются не одновременно и может действительно получиться плохой бэкап. Хотя по факту куча людей так делает.

Это для баз данных вообще ни в какие ворота, ну совсем уровень детского садика для копирования базы данных с домашней подборкой музыкальных компакт дисков. За такое на нормальной работе могут и уволить, если копировать online базу без выключения СУБД образно по условному «F5». По сути это откровенное вредительство по созданию неконсистентной полукопии базы.

А снапшот такой проблемы лишён.

Откат базы на снэпшот без доката архивными логами допустим только для примитивных систем, обычно только для внутреннего использования, работающих в режиме 8 часов x 5 дней в неделю, где утеря последних нескольких даже закоммиченных транзакций не представляет никакой серьезной опасности в силу невысокой важности данных и/или возможности их ввести повторно.

sanyo1234
() автор топика
Последнее исправление: sanyo1234 (всего исправлений: 2)
Ответ на: комментарий от AVL2

Ну очевидно, что снепшот делается после остановки СУБД. Таким образом гарантируется и консистентность и минимальное время простоя

На промышленной СУБД консистентность закоммиченных транзакций не гарантируется в случае нажатия reset на ходу? Чем это отличается от мгновенного online ZFS снэпшота ?

sanyo1234
() автор топика
Ответ на: комментарий от sanyo1234

Уточню, мой вопрос был про промышленные РСУБД типа IBM Db2, PostgreSQL и т.п., которые обычно соответствуют всем требованиям строгого ACID по крайне мере на мастере и при синхронной репликации на репликах тоже.

sanyo1234
() автор топика
Ответ на: комментарий от AVL2

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

В норме у нас есть диск или диски, в которых есть свой кеш, далее они группируются в раид контроллером со своим кешом, далее поверх всего этого появляется файловая система со своим буфером и только потом появляется СУБД со своими транзакциями, коммитами и откатами. На уровне СУБД нет ни малейшего контроля за данными на уровнях от файловой системы до диска, так что ничего он по факту гарантировать не может. Файловая система может гарантировать чуть больше, поскольку лежит на уровень ниже, а под ней все таки больше железа, чем ПО общего назначения, в котором чего только не бывает.

AVL2 ★★★★★
()
Ответ на: комментарий от AVL2

В норме у нас есть диск или диски, в которых есть свой кеш, далее они группируются в раид контроллером со своим кешом,

Кэш контроллера отключается?

далее поверх всего этого появляется файловая система со своим буфером

Буфером чтения? Если специально не включать маргинальные режимы типа sync=disabled.

и только потом появляется СУБД со своими транзакциями, коммитами и откатами.

COMMIT в СУБД требует в т.ч. и вызова sync в FS?

sanyo1234
() автор топика
Последнее исправление: sanyo1234 (всего исправлений: 2)
Ответ на: комментарий от sanyo1234

lvm2defrag

Пробовал пользоваться. Нужность сомнительна. Единственное применение — для успокоения зуда от того, что логические тома не сплошные, а разбиты на несколько частей. Скрипты помогают по инструкции сгенерировать набор вызовов pvmove, которые и производят перемещения.

Насколько я помню, это скрипты для дефрагментации простых логических томов. Про снапшоты в инструкциях ничего не было.

Интересно, дефрагментация LVM возможна online?

Единственные распространённые и надёжные инструменты для перемещения логических томов в LVM распространяются в составе утилит LVM и работают в онлайн-режиме. То есть дефрагментация только в режиме онлайн и возможна.

i-rinat ★★★★★
()
Ответ на: комментарий от sanyo1234

Мне, честно говоря, в принципе непонятен смысл твоих изысканий.

Ты готов отказаться от всего того, что было сделано для скорости и надежности за последние лет тридцать чтобы что? Отключить обратный кеш, то есть фактически, задрочить диск раз в десять быстрее и сообразно снизить скорость его работы ради чего? Чтобы твоя база вообще накернилась через пару лет работы вместо пары десятков лет? И все это вместо того, чтобы использовать ионисторы для сброса кеша на диск?

Режим синхронной записи даже для сменных флешек не так уж часто включают. Не 100%, хотя он там вполне полезен, как мера от резкого выдергивания.

Commit в DB скорее всего приведет к записи, потому что вероятность сбоя именно в те секунды после него, в которые все пишется на диск действительно минимальна. Но смысл коммита вовсе не в том, что его результаты невозможно потерять, а в том, что это контрольная точка, которую имеет смысл восстанавливать. И все на этом. Сохранилась, хорошо, от нее и пляшут. Не сохранилась, берут предыдущую.

AVL2 ★★★★★
()
Ответ на: комментарий от AVL2

Мне, честно говоря, в принципе непонятен смысл твоих изысканий.

Каких именно изысканий?

Ты готов отказаться от всего того, что было сделано для скорости и надежности за последние лет тридцать чтобы что?

Надеюсь, ты про компании Sun и Oracle, а не про Western Digital или Seagate?

Отключить обратный кеш, то есть фактически, задрочить диск раз в десять быстрее и сообразно снизить скорость его работы ради чего?

Ты из каменной пещеры только что выполз? :) Про кэширование на SSD и multi-temperature storage не слыхал?

Чтобы твоя база вообще накернилась через пару лет работы вместо пары десятков лет?

Накернилась база, на промышленной СУБД, от сбоя диска? Ахаха, чо правда, такое бывает?

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

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

Ионисторы - это для записи данных после отключения питания?

Режим синхронной записи даже для сменных флешек не так уж часто включают. Не 100%, хотя он там вполне полезен, как мера от резкого выдергивания.

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

Нука, нука, покажика описание того, как в ACID РСУБД commit, выполненный без ошибки, может потеряться.

sanyo1234
() автор топика
Последнее исправление: sanyo1234 (всего исправлений: 1)