Комментарии 34
Иначе, под нагрузкой — вас ждет «сурприз».
Кроме того, если обратиться к документации 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»
Это значит, что Монга сама откатит состояние базы к последнему валидному состоянию
Это значит, что Монга сама откатит состояние базы к последнему валидному состоянию
Это значит, что мы не получим клон базы. Такой результат не всем подходит.
Перед созданием клона мы ОБЯЗАНЫ создать моментальный снимок. Затем мы можем использовать этот снимок для создания клона, допустим через секунду или через день, не важно. Данные в этом снимке запечатлены в точный момент времени. Снимок атомарен! Мы получаем внешнюю по отношению к базе данных консистентность.
Так вот, когда база запустится, она просто отбросит все операции, которые были сделаны после последней контрольной точки, если это потребуется для сохранения внутренней консистентности.
Так как контрольные точки база делает либо каждые 60 секунд, либо каждые 2GiB данных, в зависимости от того, что случится быстрее, Разработчик получит 100% рабочую базу данных практически на момент создания снимка.
Если вас что-то смущает, поясните пожалуйста, я не понимаю.
PS мы используем это в процессе разработки больше 2х лет.
Я считаю что клон в терминах БД это точная копия данных.
Вы, кажется, считаете что это работоспособная БД с какими-то консистентными данными.
Какие-то товарищи (возможно твитер) подобным способом делают копии БД на zfs, но они предварительно лочат таблицы на запись, делают flush и только потом делают снимок. Утверждают что все хорошо и быстро.
Думаю, что проблема в понимании кроется еще и в том, что вы не работали с NoSQL базами. Там нет релляций. Коллекции данных не связаны базой данных так, как они были бы связаны в SQL. Логика сохранения консистентности частично обязана присутствовать в самом приложении в связи с этим. Архитектура такова.
С точки зрения практической ценности, описанное в статье можно называть клоном, который мы можем использовать в разработке и тестировании.
Главное преимущество описано: не нагружает сервер и не занимает время.
Я показал как можно использовать превосходную технологию. Вам решать когда и где :)
А как решить проблему что нельзя удалить исходную файловую систему, если есть клон?
То есть клон годится как временное решение или как решение когда изменяется немного данных.
Но для жизни годами — клон это не круто. Из 50 Г вы получите 100 Г и от изначальных 50 Г избавиться невозможно. Несмотря что данные уже переписаны сверху на 100 раз
docs.oracle.com/cd/E19253-01/820-0836/gbcxz/index.html
У них правда стили отвалились после перехода на HTTPS.
Как правило, кнопка для включения этой сетки находится на видном месте
Зеркало из 2 SSD, с постоянной репликацией на удаленную площадку.
Допустим программист приступает к написанию новой фичи, а тестировщик приступает к тестированию старой. Если мы будем копировать 50GiB базу для программиста, затем 50GiB базу для тестировщика, что бы они могли работать с ними в «песочнице», то нам потребовалось бы сразу дополнительно 100GiB. К тому же при копировании мы бы очень сильно нагрузили IO и CPU сервера, что длительное время сказывалось бы на Prod. Наши клиенты (это внутренний проект небольшой компании, поэтому одного боевого сервера нам хватает) испытывали бы неудобства, приложение бы тормозило.
Теперь по поводу того, что используются одни и те же блоки данных для Prod, Dev и Test. Это чудесно!!! Дело в том, что ZFS считает эти блоки 1 раз, для всех сразу, тем самым серьезно снизится нагрузка на IO. Если хотите понять почему это произойдет, почитайте как работает адаптивная замена кэша в ZFS
К тому же при копировании мы бы очень сильно нагрузили IO и CPU сервера, что длительное время сказывалось бы на Prod.
Обычно dev/test разворачивают с бэкапа. (вы же их делаете?) Для разработки отставание клона в день-два не существенно.
Если мы будем копировать 50GiB базу для программиста, затем 50GiB базу для тестировщика,
Можно сделать один клон с бэкапа, а потом делить его снепшотами как угодно. Кроме того, в зависимости от того какую вы базу используете вам может быть доступен standby, который для таких целей весьма удобен.
Обычно dev/test разворачивают с бэкапа. (вы же их делаете?) Для разработки отставание клона в день-два не существенно.
На самом деле последнее время так и происходит.
Цепочка реплик выглядит так:
Prod Server -> Backup Server (удаленная площадка) -> Hyper-V VM на ноутбуке разработчика
Но зачастую держать отдельную машину для тестирования и разработки не имеет смысла. Например базы для тестирования мы получаем именно описанным мною в статье способом!
Не забудьте, что база должна жить рядом с приложением! Если между ними будет высокий Latancy, будет худо.
То есть я хочу сказать, простую вещь. Реплики то мы делаем, но на той стороне некому запустить базу и приложение, на это нужны громадные ресурсы, которыми не обладает наш Backup Server.
Да, есть нюансы, но их обсуждение потребует отдельной статьи. Знаете я очень много думал, а не перейти ли на другую файловую систему, скажем более быструю… Но каждый раз прихожу к тому, что слишком многое теряю в этом случае. Короче мое мнение: ZFS не самая быстрая, но точно самая надежная и одна из самых удобных! Я не отрицаю, что у ZFS есть недостатки, но ничего лучше я не видел.
Самое крутое известное мне решение для БД это Oracle ASM. Естественно он строго под Oracle, а вот ZFS это последнее что я бы применил. И дело не в тормознутости, а в том, что все нормальные базы данных так или иначе имплементируют логику работы с диском напрямую (своя блочная логика например, asyncio и derectio, и т.д.). Фактически традиционная FS для базы данных лишняя сущность и её используют только для удобства админа.
И да, порой тесты и разработка гораздо эффективнее, когда работа идет с реальным данными.
И у всех случается, что в самый не подходящий момент начинает проявляется какой нибудь неприятный баг с какими нибудь «неправильными» данными, какие появились вот только сейчас, и нужно оперативно исправить… и что? Делать бэкап, разворачивать dev из него и тратить на это время? Или предоставить среду для дебаггинга уже через минуту… тут уж решайте сами, что для вас правильнее, это бизнес процесс, у всех они разные с разными данными а статья про то.
Если у вас неприятность на проде, бакап делать уже поздно.
В том то и дело, что не поздно. На проде делаются моментальные снимки каждый час по крону. Эти же снимки затем отправляются на бэкап ассинхронно.
То есть ZFS дает нам возможность версионирования прода. Мы делаем клон с любого удобного снимка. То есть у нас так и так все карты на руках.
Всегда считал, что данные не должны находиться в контейнерах.
Контейнеры в практическом смысле тоже самое что виртуальные машины.
Докер — очень своеобразная штука. Докер использует контейнеры, но можно сказать выворачивает «идею» наизнанку…
Короче в сети есть мнение что docker = container. Это не так! Возможно я сделаю об этом отдельную статью.
Контейнеры = виртуальные машины (если не брать во внимание «иллюзию» изоляции)
Как это не печально, докер сдел так, что когда люди слышат слово «контейнер», они думают «докер». Черт возьми, как сильно они ошибаются!
Почитайте как работают Linux Container (LXC) или FreeBSD jails! Мне очень повезло, я познакомился с Jails во FreeBSD еще до того как появился Docker и начал засирать мозги специалистам.
В чем проблема базы в контейнере? Ничего, кроме красоты нечеловеческой и гибкости мы не заметили… Напомню, это рабочий проект
«Всегда считал, что данные не должны находиться в контейнерах.» Ну так напиши почему ты так считал!!! Мы же здесь не в гадалку собрались играть. (Заметьте, я никому минусы не ставлю, и стараюсь ответить максимально развернуто..)
Клонирование 50Gb базы из Prod в Dev за 1 секунду без потери целостности