Где хорош Intel Optane 900p по сравнению с Samsung 950-970 Pro

а ты у нас исскуствовед, надо полагать

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

а ты у нас исскуствовед, надо полагать

Нет, увы я любитель nHibernate и даже MSSQL (а он в т.ч. и версионник!)

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

Кстати да в консерватории (на форумах DB two), вруд?

это условно раскатывание активного журнала в обе стороны

Это высказывание не имеет смысла. По крайней мере, я его не вижу. Почему «условно»? Что за обе стороны? Если пытаешься понять, есть ли какие гарантии, поверхностного понимания не хватит.

Обратно к ZFS.

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

Это высказывание не имеет смысла. По крайней мере, я его не вижу. Почему «условно»? Что за обе стороны? Если пытаешься понять, есть ли какие гарантии, поверхностного понимания не хватит.

Поверхностное понимание у тебя, вернее даже его отсутствие конкретно применительно к crash recovery DB2, не в обиду, просто ты его не изучал раньше, вот смотри:

If a database fails unexpectedly before all transactions (or units of work) are committed, or before the changes associated with committed transactions are fully written to disk, then the database is left in an inconsistent state. When a database restart is performed, these transactions are rectified during a process called crash recovery. During crash recovery, the changes associated with these transactions are first replayed from the transaction logs (we often refer to this as the Forward or Redo phase of crash recovery). Transactions which were not yet committed at the time of the database failure are then rolled back (we often refer to this as the Backward or Undo phase of crash recovery)

Обе стороны - это «туда» forward прокат завершенных транзакций «обратно» backward откат незавершенных транзакций.

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

Перед снэпшотом включаем sync=standard (я ведь писал про синхронный снэпшот), выставляем режим работы базы write suspend, когда СУБД разрешает только чтения, сбрасываем буфера базы и … снэпшотим zvol после чего еще делаем bash -c sync; Возвращаем zfs sync=disabled и поехали дальше до следующего автоматического периодического аналогичного снэпшота по крону.

у zfs нет журнала.

у zfs нет журнала.

Зато он есть у СУБД, которую предлагают ускорять через ZFS.

А хотя вот ведь какая проблемка, активные то логи не удастся применить после наката архивных?

Прошу прощения, в случае rollforward to end of logs после восстановления бэкапа активные логи тоже обрабатываются конечно же. Но вот после переключения на снэпшот не уверен, наверно тоже самое? Если так, то моя схема с моей точки зрения не должна терять ни одной завершенной транзакции.

у zfs нет журнала.

Как нет? Нет вообще или в моем случае? А позвольте узнать, что такое Intent Log при sync=standard?

И ни слова про порядок записи.

Ну давай другими словами опишу. Допустим, приложение записало блоки 4, 3, 2, 1 именно в таком порядке. Допустим, в кеше ZFS кончилось место и он решил сбросить данные на диск. В каком порядке будут записаны данные на диск? Гарантируется ли, что именно 4, 3, 2, 1? Или для ускорения он переупорядочит в виде 1, 2, 3, 4?

Возможно порядок менять особо нет смысла. Главное превратить случайный доступ в последовательный.

Зато он есть у СУБД, которую предлагают ускорять через ZFS.

Я не предлагаю ускорять СУБД именно с помощью sync=disabled в реальных промышленных условиях, там намного дешевле (с точки зрения безопасности от наличия crash recovery плюсом в full recovery) купить пару SSD-эх Intel DataCenter Edition за несколько сот тысяч руб. и они обеспечат такую же скорость в режиме sync=standard.

Просто мне стало любопытно, а сможет ли такая дикая схема обеспечить целостность базы данных DB2 с точностью до последней завершенной транзакции, и пока не вижу, почему не сможет. Просто забавно, just for fun.

превратить случайный доступ в последовательный

Но ведь это сломает журналирование в СУБД, которая хостится на таком хранилище.

При временном переключении в режим sync=standard ZFS честно отработает все fsync, какие проблемы?

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

Просто забавно, just for fun.

Интересно, насколько стали совершенные технологии хранения данных, такие как ZFS и DB2 и какие фокусы можно устраивать с помощью них на очень слабом оборудовании с добавлением промышленных SSD под SLOG и L2ARC.

Просто мне стало любопытно, а сможет ли такая дикая схема обеспечить целостность базы данных

Уже в который раз спрашиваю, как именно работает этот кеш, потому что при некоторых вариантах можно сразу сказать, что не сможет. А ты в ответ пишешь, какие настройки куда указывать. Это не то. Важны детали реализации.

с точностью до последней завершенной транзакции

С точностью до последней завершённой транзакции точно не сможет:

• Клиент присылает запросы, обёрнутые в транзакцию;
• БД отвечает, что всё зафиксировано, потому что хранилище сказало, что fsync завершился;
• Питание пропадает, кеш потерян, система перезапускается;
• Происходит восстановление консистентности БД (предположим, что успешное);
• Транзакция клиента потеряна, но клиент уверен, что фиксация произошла.

честно отработает все fsync

Сомневаюсь. «Честно отработает» можно сказать только если в точности воспроизведётся последовательность записей и fsync’ов. Но тогда смысла в кеше нет, всё упрётся в скорость накопителя.

какие проблемы?

По всей видимости, слово «журналирование» мы понимаем по-разному. В этом проблема. Ты можешь описать, как происходит процесс журналирования в СУБД?

С точностью до последней завершённой транзакции точно не сможет:

Дружище, ты скорее всего пока незнаком с тем, как работают промышленные СУБД класса DB2/MSSQL/Oracle.

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

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

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

Сомневаюсь. «Честно отработает» можно сказать только если в точности воспроизведётся последовательность записей и fsync’ов. Но тогда смысла в кеше нет, всё упрётся в скорость накопителя.

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

По всей видимости, слово «журналирование» мы понимаем по-разному. В этом проблема. Ты можешь описать, как происходит процесс журналирования в СУБД?

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

да и зачем они

Чтобы ответить на вопрос, который ты задаёшь. Нет понимания — не получится получить ответ. Можешь сколько угодно размышлять о том, что куда пропишешь, это не приближает к ответу. Ты либо понимаешь, как работает система, и тогда можешь давать квалифицированные оценки, либо не понимаешь, и тогда можешь гадать на кофейной гуще.

Они предлагают хранить

И всё это — с опорой на гарантии, которые ты отбираешь своей схемой кеширования.

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

Ты отобрал у хранилища fsync, ты же помнишь, да? Всё, нет больше доверия к точкам сохранения. Кроме того, больше нет гарантий, что база консистентна. А значит, ты не можешь уверенно сказать, какая последняя транзакция была в базе зафиксирована.

Ты рассуждаешь типа такого, если ты не понимаешь как работает микропрограмма карбюратора, то не можешь ездить на автомобиле,

как постоянный клиент такси, ответственно заявляю тебе, что ты неправ.

Для правильного обслуживания промышленной СУБД необязательно знать как работает ее внутренняя реализация целостности данных, достаточно мыслить более высокоуровневыми понятиями, которые обозначены в доках IBM DB2:

https://www.ibm.com/support/knowledgecenter/SSEPGG_11.1.0/com.ibm.db2.luw.admin.ha.doc/doc/c0006256.html

И всё это — с опорой на гарантии, которые ты отбираешь своей схемой кеширования.

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

Ты отобрал у хранилища fsync

по крону то отбираю, то возвращаю

нельзя собирать валежник / можно собирать валежник / нельзя / можно и т.д.

, ты же помнишь, да? Всё, нет больше доверия к точкам сохранения.

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

Кроме того, больше нет гарантий, что база консистентна.

Это в случае сбоя или когда?

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

А архивные логи на другом хранилище для чего?

А архивные логи на другом хранилище для чего?

И активные кстати тоже, где как раз последние транзакции и хранятся.

карбюратора

А что, карбюраторные двигатели ещё производятся?

то не можешь ездить на автомобиле

Пока не лезешь в двигатель, можешь ездить. Но ты-то лезешь ручками внутрь. И такой: «я не знаю, как это работает, и мне не надо. Думаю, если вот сюда пробку вставить, будет нормально. Я её иногда буду доставать. Что? Зачем пробка? Ну, мне кажется, что всё нормально будет.»

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

Там написано про отключение fsync? Если нет, то в обсуждаемом вопросе эти доки больше не релевантны.

по крону то отбираю, то возвращаю

Достаточно не выполнить один единственный.

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

facepalm

Это в случае сбоя или когда?

Конечно в случае сбоя! В мире, где нет сбоев, был бы ACI вместо ACID.

Но ты-то лезешь ручками внутрь.

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

Там написано про отключение fsync? Если нет, то в обсуждаемом вопросе эти доки больше не релевантны.

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

ZFS гарантирует целостность таких снэпшотов, даже если ты потом опять отключишь fsync у того же самого датасета, в случае факапа со снэпшотом НИЧЕГО не случится, ты это понимаешь?

Достаточно не выполнить один единственный.

А для чего в языках программирования (в т.ч. bash) существует команда ветвления «IF»?

sync_state=`zfs get sync database_dataset";

If [«sync_state» == «standard»]; then

все ок, поехали фризить базу …

facepalm

Ненадолго к текущему состоянию dataset, а к состоянию снэпшота - постоянное доверие (по докам ZFS, если чо).

Конечно в случае сбоя! В мире, где нет сбоев, был бы ACI вместо ACID.

Правильнее было спросить «в момент сбоя или когда».

Ну и пусть, база неконсистента в момент сбоя, нас это не волнует, потому что мы откатимся с помощью zfs rollback к консистентному старому состоянию базы и потом сделаем rollforwarf логов до самой последней транзакции из другого консистентного хранилища.

Но ты-то лезешь ручками внутрь.

Образно объясню это так:

ты рассуждаешь о сортах реализации ассемблера в кодах,

но при этом не в состоянии понять как пользоваться GW basic по толстой приятной доке Microsoft в глянцевой обложке.

БД отвечает, что всё зафиксировано, потому что хранилище сказало, что fsync завершился;
Питание пропадает, кеш потерян, система перезапускается;

Если fsync завершился, то похер, что кеш потерян. Если ты про питание хранилища, то у них есть автономный источник питания для хранения кеша.

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

так и появляются байки про туповатых обминов энтырпрайза.

Если fsync завершился, то похер, что кеш потерян.

a_buchinskiy предлагает использовать фичу ZFS «говорить приложению, что fsync() завершился успешно, но при этом его даже не запускать».

кеша

Кеш у ZFS — в ОЗУ.

А архивные логи на другом хранилище для чего?

на каком другом?

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

Он писал про ZFS ARC, который при сбое незащищен батарейкой.

Но я всю эту тему пытаюсь объяснить следующее в терминологии DBA:

Промышленные СУБД предоставляют два способа восстановления базы после сбоя:

A) быстрый crash recovery: диск базы + active logs

B) более медленный full recovery: восстановить бэкап или откатиться на снэпшот и потом накатывать архивные логи

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

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

Не знаю как вам еще объяснить.

В production конечно же лучше оставить оба шанса на восстановление: A) и B), не создавая дополнительных рисков.

на каком другом?

На котором постоянно включен режив sync=standard ессно.

так и появляются байки про туповатых обминов энтырпрайза.

А у обминов DBA складывается подобное впечатление о тех, кто не понимает основные высокоуровневые принципы recovery базы на промышленной СУБД.

и в чём поинт? у тебя вся эта балалайка будет работать со скоростью записи логов.

Это получится использование ZFS как базой данных для отслеживания изменений без полной записи. Копировать куда-то можно. Просто фанатики тормозов будут тем самым играть на страхах, чтобы найти повод не использовать такой подход. Это как минимум высвободит от простоя сервер. А вообще что мешает скидывать данные с виртуального пула не останавливая работу всей базы? На SSD скоростей вроде бы хватает. Ну там было 24 SSD диска, сделали 6 рейдов по 4 диска в raidz2 и полетели с диким улюлюканием. По-моему тут избыточность на избыточности получается.

точно не у тех, кто не понимает, как их база работает. хотя, раздутое чсв часто идёт в комплекте с таком вот «не надо знать». высокоуровневые принципы - это где-то на уровне эникея.

и в чём поинт? у тебя вся эта балалайка будет работать со скоростью записи логов.

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

Активные логи размещаем на небольшом промышленном зеркале SSD, архивные неспешно и самое главное ПОСЛЕДОВАТЕЛЬНО выталкиваем на другое синхронное хранилище.

Профит в том, что быстрые SSD надо только под активные логи, а это совсем немного, профит ! :)

высокоуровневые принципы - это где-то на уровне эникея.

Дооаа, дока IBM по DB2 - это как раз про аникей, плюсую.

Хватит путать программиста и администратора. Эникей это вообще начальный уровень.

Ну это «генитально», да.