« Rev
@ru_zfs   789
Fwd »


Vladislav
Журнал обычной ФС (etx4) можно привести к CoW путём добавления отдельного диска под журнал и флагом journal=data Как в такой ситуации себя почувствует БД я не рискну предположить
Δαρθ
В моей ситуации, например, VM с zvolом работала (делая кучу синхронных записей) БЫСТРЕЕ чем на том же диске голой ж... напрямую замапленном в VM
Δαρθ
Откуда можно сделать вывод, что в ZIL/журнал/wtf идёт всё, в тч и данные
Δαρθ
в zfs
Δαρθ
нельзя. и об этом написано в приведенной ссылке. но я не буду спорить, не интеренсно
В ext4 по журналу откатываются/завершаются неоконченные изменения в структуру ФС. А в ZFS -- в журнал/какеготам сливаются транзакции, которые вотпрямщяс было бы ОЧЕНь ДОЛГО фигурно записывать во все деревья и суперблоки
Vladislav
Откуда можно сделать вывод, что в ZIL/журнал/wtf идёт всё, в тч и данные
??? "Транзакции этих данных, включая сами данные" Я буквально и написал?
Vladislav
Посмотри как работает ZIL и для каких сценариев
Δαρθ
Синхронные записи -- эт овсе записи до вызова fsync(). так что фактически да.
Δαρθ
иначе очень странно было бы что поздняя синхронная запись прошла а раняя несинхронная - нет
Vladislav
иначе очень странно было бы что поздняя синхронная запись прошла а раняя несинхронная - нет
И такое может быть, потому что не синхронные записи лежат в раме 5 секунд по умолчанию
Δαρθ
(это при наличии slog)
без слога zil просто на том же диске
Vladislav
Синхронные же помещаются и в рам и на zil
Δαρθ
И такое может быть, потому что не синхронные записи лежат в раме 5 секунд по умолчанию
ну то есть БД записала 1 байт в начало файла просто так а потом 2ой байт в конец синхронно. И по крешу останется только 2ой? если будет так, то ни о какой консистентности данных для БД можно не говорить
Vladislav
БД не пишет просто так?
Oracle DBA
Ребята база пишет файл с данными асинхронно в разные части файла, раз определенное время, на каждой бд свое, делает синхронизацию всего файла, но это не означает, что соседний файл она тоже синхронизирует. В итоге при отключении/снепшот мы получаем кашу внутри файла с данными. Чем сильнее загружена бд, тем больше не конситентна бд на диске( согласованность) данных и данных в памяти. Если на пальцах, то у нас есть таблица с 1 по 100 записать если читать из бд, а момент времени на диске только с1 по 20 и с 90 по 100 записи, а остальные сидят в памяти и ждут своего времени записи на диск, но бд считает что транзакция уже выполнена и данные об этом записаны в лог транзакции.
Vladislav
Видимо все же пишет
Vladislav
Поэтому и важно готовить БД к отключению/снапу
Δαρθ
Поэтому и важно готовить БД к отключению/снапу
Так БД только на такое поведение (что fsync() флашит ВСЕ предыдущие записи) и может рассчитывать. У неё буквально нет никаких других ручек
Δαρθ
Да и сама ФС при работе с диском рассчитывает ровно на то же самое
Vladislav
Если бд считает, что данные записаны, а на самом деле они в памяти, то у вас проблемы.
(кхм, если БД считает, что данные записаны без использования синка, то есть проблема)
Δαρθ
Поэтому и важно готовить БД к отключению/снапу
Я собсно поднял вопрос о том, что снапшот сделанный в момент времени N, включает в себя все изменения от момента времени M, когда последний txg отписали в дерево до момента N, где отписанное ещё в ZILе, или нет.
Δαρθ
Но на консистентность состояния БД это не должно влиять, да. Только на то насколько в прошлом будет снапшот
Vladislav
Но на консистентность состояния БД это не должно влиять, да. Только на то насколько в прошлом будет снапшот
Если БД записала синхронно поменять блок А, Б, а потом асинхронном А и С, то пизда БД
Vladislav
Наоборот тоже пизда
Δαρθ
или может даже CoW деревья
Oracle DBA
Если бд считает, что данные записаны, а на самом деле они в памяти, то у вас проблемы.
Это нормальная работа бд, так как она работает не файлами, а с блоками в внутри файлов. И чтоб все было красиво ее нужно правильно выключать, а не по питанию. Так же есть разные внутренние механизмы, чтоб снизить кол-во данных не записанных на диск, которые работают через определенное время, как в zfs принудительная запись каждые 5 сек.
Δαρθ
А куда она из пишет?)))))
В файлы, синхронно
Vladislav
В файлы, синхронно
Так синхронно пишем или нет?
Oracle DBA
А куда она из пишет?)))))
На диск пишет, и не факт что это тот же диск, на котором хранятся данные. Обычно для этого выдают отдельные диски, чтоб быстро записывали, по сравнению с дисками для самих данных
Oracle DBA
Так синхронно пишем или нет?
Синхронно, только логи работы(архивлоги, редологи и т.д.)
Oracle DBA
Блоки с данными в файлы пишутся асинхронно, это компромис по скорости работы с данными внутри БД.
Δαρθ
Блоки с данными в файлы пишутся асинхронно, это компромис по скорости работы с данными внутри БД.
Если они пишутся в файлы на той же ФС то вызов fsync() будет означать что весь массив записей надо синхронно зафлашить
Δαρθ
Собсно в ZFS ZIL один на весь раздел (пул)
Δαρθ
А если разные диски етц. это уже заморочки не ZFS а БД из ника :)
Oracle DBA
Если они пишутся в файлы на той же ФС то вызов fsync() будет означать что весь массив записей надо синхронно зафлашить
Если они были отправлены на запись, но бд может их поставить ВОВ нутренюю очередь на запись через 5 сек, а снепшот/sync получилось сделать через 2 сек.
Δαρθ
Ну и ZFS немного похуй на fsync
С какого перепуга?
Vladislav
С какого перепуга?
Момент, найду из OpenZFS подтверждение
Vladislav
Оракл ZFS все же может немного отличаться в этом плане
Δαρθ
у ZFS есть 3 режима, всё всегда синхронное, всё всегда несинхронное, fsync(). Хотя про 1ый хз, может гоню
George
Ну и ZFS немного похуй на fsync
смотря какой sync выставишь, по дефолту sync=standard, это аналогичное поведение любой другой ФС (асинхронная запись, fsync)
George
sync=disabled просто игнорит fsyncи
Алексей
даже и не знаю как сказать. слегка в перемешку
в общем проц тоже не помог, 200мбай/сек предел
Ортонормированная
Я запутался. Все таки можно использовать снэпшоты для бд?
Andrey
да - можно
Andrey
только не тупо делать снапшот, а сказать БД, что сейчас будет снапшот у каждой БД свои слова, чтобы это сказать
Δαρθ
только не тупо делать снапшот, а сказать БД, что сейчас будет снапшот у каждой БД свои слова, чтобы это сказать
А если тупо сделать -- для БД в случае раскатывания снапшота это будет как креш
Vladislav
Ну скажем так, если приложение гонит read sync, то оно приоритетней, чем write sync
Vladislav
только не тупо делать снапшот, а сказать БД, что сейчас будет снапшот у каждой БД свои слова, чтобы это сказать
Да, это с самого начала сказали, осталось лишь понять как для постгре сказать это правильно, а то мнений, что даже pg_dump не приводит к консистетном состоянию
Andrey
А если тупо сделать -- для БД в случае раскатывания снапшота это будет как креш
Можно и так, только зачем себе искать приключения на одно место?
Andrey
у postgres - checkpoint?
pg_start_backup snapshot pg_stop_backup
Vladislav
Ну и ZFS немного похуй на fsync
И да, неправ, это я перепутал с https://github.com/openzfs/zfs/issues/224
Ортонормированная
pg_start_backup snapshot pg_stop_backup
а норм ли будут работать o_direct, fsync?
Andrey
что вы хотите - снапшот БД рабочий или разобраться со сферическим конем ?
Andrey
https://postgrespro.ru/docs/postgresql/9.6/continuous-archiving 25.3.3.1. Немонопольное резервное копирование на низком уровне можете вообще тупо без снапшотов со снапшотами - быстрее выходите из режима pg_start_backup и меньше нагрузка н БД в этом случае
Ортонормированная
что вы хотите - снапшот БД рабочий или разобраться со сферическим конем ?
Снапшот хочу, потому что долго восстанавливаться из вала очень долго, если база большая, то можно днями
Δαρθ
И да, неправ, это я перепутал с https://github.com/openzfs/zfs/issues/224
Да, чото помню такое когда в qemu пытался direct ставить на zvol
Ортонормированная
Да, чото помню такое когда в qemu пытался direct ставить на zvol
что за аббревиатуры ZIL ZVO
Oracle DBA
pg_start_backup snapshot pg_stop_backup
Нужно не забыть ещё sync в os сделать после старт бекап.
Nikita
pg_start_backup snapshot pg_stop_backup
собсно, в zfstools именно так и сделано: when 'postgresql' sql_pre_query = "SELECT PG_START_BACKUP('zfs-auto-snapshot');" sql_post_query = "SELECT PG_STOP_BACKUP();" zfs_cmd = cmd cmd = %Q[(psql -c "#{sql_pre_query}" postgres ; #{zfs_cmd} ) ; psql -c "#{sql_post_query}" postgres] end https://github.com/bdrewery/zfstools/blob/master/lib/zfstools/snapshot.rb
Станислав
Так и работает. Снапшот всегда = оторвали сторадж у процесса. Без подготовки БД к этому - разницы между снапшотом и дёрнули питание нет
Думаю ты не прав. Уверен на 99.9%, чтобы снапшот включает в себя данные, которые ещё не сбросились на диск с буфера. И если БД передала данные без синха, после чего сразу сделан снапшот и не было резкого выключения питания, то для БД это будет означать, что все данные действительно записались на диск. П.С. СУБД на то и СУБД - у неё также транзакционная система и в случае недостачи данных, которые передавались без синха, есть контрольные данные, которые с записаны с синком и произойдёт откат до определенного txg на уровне БД
Станислав
каким блять образом она включает данные из RAM?
А каким образом данные из RAM будут корректно прочитаны сразу после их передачи туда?
Ivan
каким блять образом она включает данные из RAM?
если в гипервизоре с опцией снапа с рамой запустить )
Станислав
каким блять образом она включает данные из RAM?
Ты же не хочешь сказать, что после сохранения файла тебе нужно подождать 5сек, чтобы его вновь открыть и увидеть новые данные? Они же сразу будут доступны
Vladislav
Ты же не хочешь сказать, что после сохранения файла тебе нужно подождать 5сек, чтобы его вновь открыть и увидеть новые данные? Они же сразу будут доступны
??? Если я выдерну питание - они не будут доступны да И, внезапно, но к TXG группе можно обращаться даже когда она в RAM
Станислав
??? Если я выдерну питание - они не будут доступны да И, внезапно, но к TXG группе можно обращаться даже когда она в RAM
Вот вот. Кто сказал, что синк не делает тоже самое с TXG? Это, как минимум, было бы неразумно
« Rev
@ru_zfs   789
Fwd »