Я понял, вы придираетесь к мелочам, вместо того что бы оценить, а нужно ли то, что вы предлагаете разработчикам и тестировщикам? Всегда стоит конкретная задача, мы не делаем сферических коней в вакуме. Так вот, копия такого уровня консистентности, подходит как для разработки, так и для тестирования.
Думаю, что проблема в понимании кроется еще и в том, что вы не работали с NoSQL базами. Там нет релляций. Коллекции данных не связаны базой данных так, как они были бы связаны в SQL. Логика сохранения консистентности частично обязана присутствовать в самом приложении в связи с этим. Архитектура такова.
«Не говоря о том что ZFS сам по себе не быстр (но это уже offtop)»
Да, есть нюансы, но их обсуждение потребует отдельной статьи. Знаете я очень много думал, а не перейти ли на другую файловую систему, скажем более быструю… Но каждый раз прихожу к тому, что слишком многое теряю в этом случае. Короче мое мнение: ZFS не самая быстрая, но точно самая надежная и одна из самых удобных! Я не отрицаю, что у ZFS есть недостатки, но ничего лучше я не видел.
Не пониманию ваше непонимание. Попробую еще раз объяснить.
Перед созданием клона мы ОБЯЗАНЫ создать моментальный снимок. Затем мы можем использовать этот снимок для создания клона, допустим через секунду или через день, не важно. Данные в этом снимке запечатлены в точный момент времени. Снимок атомарен! Мы получаем внешнюю по отношению к базе данных консистентность.
Так вот, когда база запустится, она просто отбросит все операции, которые были сделаны после последней контрольной точки, если это потребуется для сохранения внутренней консистентности.
Так как контрольные точки база делает либо каждые 60 секунд, либо каждые 2GiB данных, в зависимости от того, что случится быстрее, Разработчик получит 100% рабочую базу данных практически на момент создания снимка.
Если вас что-то смущает, поясните пожалуйста, я не понимаю.
PS мы используем это в процессе разработки больше 2х лет.
Зеркало из 2 SSD, с постоянной репликацией на удаленную площадку.
Допустим программист приступает к написанию новой фичи, а тестировщик приступает к тестированию старой. Если мы будем копировать 50GiB базу для программиста, затем 50GiB базу для тестировщика, что бы они могли работать с ними в «песочнице», то нам потребовалось бы сразу дополнительно 100GiB. К тому же при копировании мы бы очень сильно нагрузили IO и CPU сервера, что длительное время сказывалось бы на Prod. Наши клиенты (это внутренний проект небольшой компании, поэтому одного боевого сервера нам хватает) испытывали бы неудобства, приложение бы тормозило.
Теперь по поводу того, что используются одни и те же блоки данных для Prod, Dev и Test. Это чудесно!!! Дело в том, что ZFS считает эти блоки 1 раз, для всех сразу, тем самым серьезно снизится нагрузка на IO. Если хотите понять почему это произойдет, почитайте как работает адаптивная замена кэша в ZFS
Сюрприза не будет. Указанная операция не имеет смысла, так как клонирование production базы проводится для тестирования либо для дальнейшей разработки. То есть мы хотим получить точную копию Production базы в Dev или Test окружении. При этом мы естественно не хотим останавливать Prod (что вы предлагаете сделать).
Кроме того, если обратиться к документации Wired Tiger, то мы увидим следующее:
«MongoDB configures WiredTiger to create checkpoints (i.e. write the snapshot data to disk) at intervals of 60 seconds or 2 gigabytes of journal data.
During the write of a new checkpoint, the previous checkpoint is still valid. As such, even if MongoDB terminates or encounters an error while writing a new checkpoint, upon restart, MongoDB can recover from the last valid checkpoin»
Это значит, что Монга сама откатит состояние базы к последнему валидному состоянию
Насчет наушников — в видео нет голосового сопровождения, только аннотации. Про подачу материала я понял. Я попробую снять статью с публикации и добавить полное текстовое описание скринкаста. Спасибо за отзыв!
Если у вас не контейнеры, а виртуальные машины, то диски хранятся на zfs volume (zvol), а для них Proxmox делает по умолчанию размер блока 8кб. Попробуйте использовать больший размер блока (128кб, как в датасетах). Так же могут наблюдаться проблемы с IO из за swap раздела на zfs volume. Попробуйте отмонтировать swap, если проблемы с IO исчезнут, используйте другую FS для SWAP или настройте оптимальный размер блока.
Вообще имея zfs можно вместо бэкапов делать реплики на уровне файловой системы. Это вообще не нагружает систему, т.к. Zfs не нужно сравнивать файлы и совершать какую либо работу, что бы получить разницу между 2 снимками.
Zol отлично работает из коробки. Не хватает только поддержки trim для SSD, но это скорее из-за из параноидально безопасного подхода разработчиков к сохранности данных. Многие производители SSD реализуют trim настолько плохо, что были неоднократные случаи потери данных на EXT4 и других фс. Погуглите.
Память не проблема. ARC кэш можно ограничить или отключить через файл
/etc/modprobe.d/zfs.conf
options zfs zfs_arc_max=8299967296 # (по умолчанию 50% от общего объема памяти)
# arc_sys_free — количество памяти которое нужно оставлять свободным. По умолчанию 1\64 от общего объема :)
options zfs zfs_arc_sys_free=6442450944 # (оставлять 6 гб свободной памяти)
Это понятно. К примеру мы случайно сделали destroy, затем сразу zpool export и пытаемся подключить пул со старой TXG. Проблема именно подключить… Драйвер ZFS не дает использовать старую TXG запись насколько я понял. Если есть специалисты, которые смогли найти решение данной проблемы, заклинаю, напишите как это сделать!
Возможно в оперативку не влезли служебные данные нужные для дедупликации. Тогда системе пришлось сбросить это на диск, а к этой таблице нужно обращаться при каждой операции чтения и записи. Там расход примерно 8гб ОЗУ на 1 тб данных
Подскажите возможно ли после уничтожения датасета заставить ZFS вернуться к старому состоянию базы данных, где этот датасет будет еще живой чтобы спасти данные? Вроде бы есть «мифический» способ сделать это использую флаг -T и указав id транзакции до дестроя при импорте, но как бы я не старался, у меня не вышло.
Команда выглядит примерно так:
zpool import -N -o readonly=on -f -R /pool -F -T <transaction_id>
Спасибо! бесценная статья! Я давно работаю с LXC и LXD, но с докером не сложилось, в том числе потому, что я не смог разобраться как показать контейнеру сколько памяти ему доступно…
Думаю, что проблема в понимании кроется еще и в том, что вы не работали с NoSQL базами. Там нет релляций. Коллекции данных не связаны базой данных так, как они были бы связаны в SQL. Логика сохранения консистентности частично обязана присутствовать в самом приложении в связи с этим. Архитектура такова.
Да, есть нюансы, но их обсуждение потребует отдельной статьи. Знаете я очень много думал, а не перейти ли на другую файловую систему, скажем более быструю… Но каждый раз прихожу к тому, что слишком многое теряю в этом случае. Короче мое мнение: ZFS не самая быстрая, но точно самая надежная и одна из самых удобных! Я не отрицаю, что у ZFS есть недостатки, но ничего лучше я не видел.
Перед созданием клона мы ОБЯЗАНЫ создать моментальный снимок. Затем мы можем использовать этот снимок для создания клона, допустим через секунду или через день, не важно. Данные в этом снимке запечатлены в точный момент времени. Снимок атомарен! Мы получаем внешнюю по отношению к базе данных консистентность.
Так вот, когда база запустится, она просто отбросит все операции, которые были сделаны после последней контрольной точки, если это потребуется для сохранения внутренней консистентности.
Так как контрольные точки база делает либо каждые 60 секунд, либо каждые 2GiB данных, в зависимости от того, что случится быстрее, Разработчик получит 100% рабочую базу данных практически на момент создания снимка.
Если вас что-то смущает, поясните пожалуйста, я не понимаю.
PS мы используем это в процессе разработки больше 2х лет.
Зеркало из 2 SSD, с постоянной репликацией на удаленную площадку.
Допустим программист приступает к написанию новой фичи, а тестировщик приступает к тестированию старой. Если мы будем копировать 50GiB базу для программиста, затем 50GiB базу для тестировщика, что бы они могли работать с ними в «песочнице», то нам потребовалось бы сразу дополнительно 100GiB. К тому же при копировании мы бы очень сильно нагрузили IO и CPU сервера, что длительное время сказывалось бы на Prod. Наши клиенты (это внутренний проект небольшой компании, поэтому одного боевого сервера нам хватает) испытывали бы неудобства, приложение бы тормозило.
Теперь по поводу того, что используются одни и те же блоки данных для Prod, Dev и Test. Это чудесно!!! Дело в том, что ZFS считает эти блоки 1 раз, для всех сразу, тем самым серьезно снизится нагрузка на IO. Если хотите понять почему это произойдет, почитайте как работает адаптивная замена кэша в ZFS
docs.oracle.com/cd/E19253-01/820-0836/gbcxz/index.html
У них правда стили отвалились после перехода на HTTPS.
Кроме того, если обратиться к документации Wired Tiger, то мы увидим следующее:
«MongoDB configures WiredTiger to create checkpoints (i.e. write the snapshot data to disk) at intervals of 60 seconds or 2 gigabytes of journal data.
During the write of a new checkpoint, the previous checkpoint is still valid. As such, even if MongoDB terminates or encounters an error while writing a new checkpoint, upon restart, MongoDB can recover from the last valid checkpoin»
Это значит, что Монга сама откатит состояние базы к последнему валидному состоянию
Вообще имея zfs можно вместо бэкапов делать реплики на уровне файловой системы. Это вообще не нагружает систему, т.к. Zfs не нужно сравнивать файлы и совершать какую либо работу, что бы получить разницу между 2 снимками.
echo 8299967296 >> /sys/module/zfs/parameters/zfs_arc_max
echo 6442450943 >> /sys/module/zfs/parameters/zfs_arc_sys_free
/etc/modprobe.d/zfs.conf
options zfs zfs_arc_max=8299967296 # (по умолчанию 50% от общего объема памяти)
# arc_sys_free — количество памяти которое нужно оставлять свободным. По умолчанию 1\64 от общего объема :)
options zfs zfs_arc_sys_free=6442450944 # (оставлять 6 гб свободной памяти)
Команда выглядит примерно так:
zpool import -N -o readonly=on -f -R /pool -F -T <transaction_id>