Comments 34
Нет, нет и ещё раз нет. Всякие видео и скринкасты ужасны в качестве подачи материала. Даже доклады с конференций желательно выкладывать вместе с текстовой расшифровкой. Почему? Они не индексируются, времени на изучение тратится больше, прямая навигация затруднительна, в конце концов у меня под рукой может банально не быть наушников.
Если не путаю — рекомендуется или останавливать mongodb или использовать db.fsyncLock()/db.fsyncUnlock().
Иначе, под нагрузкой — вас ждет «сурприз».
Иначе, под нагрузкой — вас ждет «сурприз».
Сюрприза не будет. Указанная операция не имеет смысла, так как клонирование 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»
Это значит, что Монга сама откатит состояние базы к последнему валидному состоянию
Кроме того, если обратиться к документации 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х лет.
Перед созданием клона мы ОБЯЗАНЫ создать моментальный снимок. Затем мы можем использовать этот снимок для создания клона, допустим через секунду или через день, не важно. Данные в этом снимке запечатлены в точный момент времени. Снимок атомарен! Мы получаем внешнюю по отношению к базе данных консистентность.
Так вот, когда база запустится, она просто отбросит все операции, которые были сделаны после последней контрольной точки, если это потребуется для сохранения внутренней консистентности.
Так как контрольные точки база делает либо каждые 60 секунд, либо каждые 2GiB данных, в зависимости от того, что случится быстрее, Разработчик получит 100% рабочую базу данных практически на момент создания снимка.
Если вас что-то смущает, поясните пожалуйста, я не понимаю.
PS мы используем это в процессе разработки больше 2х лет.
А что такое по вашему клон? Думаю корень наших непониманий в этом.
Я считаю что клон в терминах БД это точная копия данных.
Вы, кажется, считаете что это работоспособная БД с какими-то консистентными данными.
Какие-то товарищи (возможно твитер) подобным способом делают копии БД на zfs, но они предварительно лочат таблицы на запись, делают flush и только потом делают снимок. Утверждают что все хорошо и быстро.
Я считаю что клон в терминах БД это точная копия данных.
Вы, кажется, считаете что это работоспособная БД с какими-то консистентными данными.
Какие-то товарищи (возможно твитер) подобным способом делают копии БД на zfs, но они предварительно лочат таблицы на запись, делают flush и только потом делают снимок. Утверждают что все хорошо и быстро.
Я понял, вы придираетесь к мелочам, вместо того что бы оценить, а нужно ли то, что вы предлагаете разработчикам и тестировщикам? Всегда стоит конкретная задача, мы не делаем сферических коней в вакуме. Так вот, копия такого уровня консистентности, подходит как для разработки, так и для тестирования.
Думаю, что проблема в понимании кроется еще и в том, что вы не работали с NoSQL базами. Там нет релляций. Коллекции данных не связаны базой данных так, как они были бы связаны в SQL. Логика сохранения консистентности частично обязана присутствовать в самом приложении в связи с этим. Архитектура такова.
Думаю, что проблема в понимании кроется еще и в том, что вы не работали с NoSQL базами. Там нет релляций. Коллекции данных не связаны базой данных так, как они были бы связаны в SQL. Логика сохранения консистентности частично обязана присутствовать в самом приложении в связи с этим. Архитектура такова.
Мне казалось, что клонирование это создание точной копии на другом носители с возможностью транспортировки в другое место планеты/солнечной системы/галактики. А так получается copy-on-write копия.
То, о чем вы говорите, это уже репликация (репликацию можно сделать в другую файловую систему, в файл, или на удаленную площадку).
С точки зрения практической ценности, описанное в статье можно называть клоном, который мы можем использовать в разработке и тестировании.
Главное преимущество описано: не нагружает сервер и не занимает время.
Я показал как можно использовать превосходную технологию. Вам решать когда и где :)
С точки зрения практической ценности, описанное в статье можно называть клоном, который мы можем использовать в разработке и тестировании.
Главное преимущество описано: не нагружает сервер и не занимает время.
Я показал как можно использовать превосходную технологию. Вам решать когда и где :)
А как решить проблему что нельзя удалить исходную файловую систему, если есть клон?
То есть клон годится как временное решение или как решение когда изменяется немного данных.
Но для жизни годами — клон это не круто. Из 50 Г вы получите 100 Г и от изначальных 50 Г избавиться невозможно. Несмотря что данные уже переписаны сверху на 100 раз
Нет такой проблемы. Почитайте про zfs promote
docs.oracle.com/cd/E19253-01/820-0836/gbcxz/index.html
У них правда стили отвалились после перехода на HTTPS.
docs.oracle.com/cd/E19253-01/820-0836/gbcxz/index.html
У них правда стили отвалились после перехода на HTTPS.
Впредь при монтаже рекомендую придерживаться так называемой Title/Action Safe Area, потому что при перемотке видео вылезает полоса прокрутки и закрывает текст
Как правило, кнопка для включения этой сетки находится на видном месте
Как правило, кнопка для включения этой сетки находится на видном месте
В данном случае, нагрузка на Dev'е будет сказываться на Prod, (т.к. обе бд по сути будут использовать одни и те же блоки, пока они не изменены). Это важный момент, мало кого устраивает такой расклад. Это надо оговаривать. Не говоря о том что ZFS сам по себе не быстр (но это уже offtop).
Поясню свою точку зрения. Допустим для проекта мы арендуем вот такую машину www.hetzner.com/dedicated-rootserver/ex51-ssd
Зеркало из 2 SSD, с постоянной репликацией на удаленную площадку.
Допустим программист приступает к написанию новой фичи, а тестировщик приступает к тестированию старой. Если мы будем копировать 50GiB базу для программиста, затем 50GiB базу для тестировщика, что бы они могли работать с ними в «песочнице», то нам потребовалось бы сразу дополнительно 100GiB. К тому же при копировании мы бы очень сильно нагрузили IO и CPU сервера, что длительное время сказывалось бы на Prod. Наши клиенты (это внутренний проект небольшой компании, поэтому одного боевого сервера нам хватает) испытывали бы неудобства, приложение бы тормозило.
Теперь по поводу того, что используются одни и те же блоки данных для Prod, Dev и Test. Это чудесно!!! Дело в том, что ZFS считает эти блоки 1 раз, для всех сразу, тем самым серьезно снизится нагрузка на IO. Если хотите понять почему это произойдет, почитайте как работает адаптивная замена кэша в ZFS
Зеркало из 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 сам по себе не быстр (но это уже offtop)»
Да, есть нюансы, но их обсуждение потребует отдельной статьи. Знаете я очень много думал, а не перейти ли на другую файловую систему, скажем более быструю… Но каждый раз прихожу к тому, что слишком многое теряю в этом случае. Короче мое мнение: ZFS не самая быстрая, но точно самая надежная и одна из самых удобных! Я не отрицаю, что у ZFS есть недостатки, но ничего лучше я не видел.
Да, есть нюансы, но их обсуждение потребует отдельной статьи. Знаете я очень много думал, а не перейти ли на другую файловую систему, скажем более быструю… Но каждый раз прихожу к тому, что слишком многое теряю в этом случае. Короче мое мнение: ZFS не самая быстрая, но точно самая надежная и одна из самых удобных! Я не отрицаю, что у ZFS есть недостатки, но ничего лучше я не видел.
Самое крутое известное мне решение для БД это Oracle ASM. Естественно он строго под Oracle, а вот ZFS это последнее что я бы применил. И дело не в тормознутости, а в том, что все нормальные базы данных так или иначе имплементируют логику работы с диском напрямую (своя блочная логика например, asyncio и derectio, и т.д.). Фактически традиционная FS для базы данных лишняя сущность и её используют только для удобства админа.
Подача в виде скринкаста имеет право на жизнь. Она очень поможет новичкам, которым еще сложно ориентироваться в настройках и интерфейсах нового ПО.
UFO just landed and posted this here
Отчасти вы конечно же правы. Но вы снова забываете о контексте. Нельзя бездумно перенимать чужой опыт. Как я уже говорил, наш проект для внутренних нужд. Там нет персональных данных. Кроме того им занимается, внимание — 1 senior Fullstack .net программист, который является нашим сотрудником, работает fulltime. У него и так есть доступ ко многим вещам.
И да, порой тесты и разработка гораздо эффективнее, когда работа идет с реальным данными.
И да, порой тесты и разработка гораздо эффективнее, когда работа идет с реальным данными.
Ну, насколько я понял, статья о связке технологий, позволяющей очень гибко управлять инфраструктурой, а не о бизнес процессах и данных пользователей…
И у всех случается, что в самый не подходящий момент начинает проявляется какой нибудь неприятный баг с какими нибудь «неправильными» данными, какие появились вот только сейчас, и нужно оперативно исправить… и что? Делать бэкап, разворачивать dev из него и тратить на это время? Или предоставить среду для дебаггинга уже через минуту… тут уж решайте сами, что для вас правильнее, это бизнес процесс, у всех они разные с разными данными а статья про то.
И у всех случается, что в самый не подходящий момент начинает проявляется какой нибудь неприятный баг с какими нибудь «неправильными» данными, какие появились вот только сейчас, и нужно оперативно исправить… и что? Делать бэкап, разворачивать dev из него и тратить на это время? Или предоставить среду для дебаггинга уже через минуту… тут уж решайте сами, что для вас правильнее, это бизнес процесс, у всех они разные с разными данными а статья про то.
UFO just landed and posted this here
Если у вас неприятность на проде, бакап делать уже поздно.
В том то и дело, что не поздно. На проде делаются моментальные снимки каждый час по крону. Эти же снимки затем отправляются на бэкап ассинхронно.
То есть ZFS дает нам возможность версионирования прода. Мы делаем клон с любого удобного снимка. То есть у нас так и так все карты на руках.
Не понял, база монго находится внутри контейнера? Серьезно?
Всегда считал, что данные не должны находиться в контейнерах.
Всегда считал, что данные не должны находиться в контейнерах.
Вы очевидно путаете контейнеры и Docker :)
Контейнеры в практическом смысле тоже самое что виртуальные машины.
Докер — очень своеобразная штука. Докер использует контейнеры, но можно сказать выворачивает «идею» наизнанку…
Короче в сети есть мнение что docker = container. Это не так! Возможно я сделаю об этом отдельную статью.
Контейнеры = виртуальные машины (если не брать во внимание «иллюзию» изоляции)
Как это не печально, докер сдел так, что когда люди слышат слово «контейнер», они думают «докер». Черт возьми, как сильно они ошибаются!
Почитайте как работают Linux Container (LXC) или FreeBSD jails! Мне очень повезло, я познакомился с Jails во FreeBSD еще до того как появился Docker и начал засирать мозги специалистам.
Контейнеры в практическом смысле тоже самое что виртуальные машины.
Докер — очень своеобразная штука. Докер использует контейнеры, но можно сказать выворачивает «идею» наизнанку…
Короче в сети есть мнение что docker = container. Это не так! Возможно я сделаю об этом отдельную статью.
Контейнеры = виртуальные машины (если не брать во внимание «иллюзию» изоляции)
Как это не печально, докер сдел так, что когда люди слышат слово «контейнер», они думают «докер». Черт возьми, как сильно они ошибаются!
Почитайте как работают Linux Container (LXC) или FreeBSD jails! Мне очень повезло, я познакомился с Jails во FreeBSD еще до того как появился Docker и начал засирать мозги специалистам.
Мне вот интересно, за что минусуют… написали бы, не поленились. Я искренне не понимаю.
В чем проблема базы в контейнере? Ничего, кроме красоты нечеловеческой и гибкости мы не заметили… Напомню, это рабочий проект
«Всегда считал, что данные не должны находиться в контейнерах.» Ну так напиши почему ты так считал!!! Мы же здесь не в гадалку собрались играть. (Заметьте, я никому минусы не ставлю, и стараюсь ответить максимально развернуто..)
В чем проблема базы в контейнере? Ничего, кроме красоты нечеловеческой и гибкости мы не заметили… Напомню, это рабочий проект
«Всегда считал, что данные не должны находиться в контейнерах.» Ну так напиши почему ты так считал!!! Мы же здесь не в гадалку собрались играть. (Заметьте, я никому минусы не ставлю, и стараюсь ответить максимально развернуто..)
Sign up to leave a comment.
Клонирование 50Gb базы из Prod в Dev за 1 секунду без потери целостности