БД для docker

А почему ты выбираешь БД не под приложение, а под докер?

Никогда не клади БД в докер. Сколько раз уже говорено и писано об этом. В докере не должно быть данных. Точка.

Базу данных в докере вообще не лучшая идея запускать. А раз ты не знаешь, что такое базы данных и для чего они нужны, советую начать с mysql. Опыт должен приходить через боль.

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

выступает параметр наименьших проблем при внезапных отключениях

Если такой параметр выступает... вы делаете что-то не так.
У вас какой-то сумасшедший контейнеры рандомно кладёт или UPS'ов нету?
Откуда такая специфика?

Тогда вопрос остается к последним двум.

Не мучай себя, бери перкону1

и выступает параметр наименьших проблем при внезапных отключениях.

При «внезапных отключениях» любая субд может лечь. О чем вам уже намекнули выше. Так же вам написали что держать субд в докере не очень правильное решение. Хотя могут быть исключения когда эта субд по факту и не сильно используется приложением. Бывают такие в которых заложен функционал, но именно его вы активно не используете.

Походу, тебе не зря MySQL посоветовали.

С postgresql просто в одном из тредов было замечено, что при завершении контейнера не успевает завершаться сам сервис postgres.

В моем случае, на некоторых тестовых приложениях из-за этого крашилась база. Это конечно не беда, так как база генерировались при новых билдах с нуля. Чем был и удобен docker.

Теперь я эксперементирую в домашних условиях. Отсюда и возник вопрос на счет БД.

С postgresql просто в одном из тредов было замечено, что при завершении контейнера не успевает завершаться сам сервис postgres.

Если контейнер запускается вокруг демона PG, как оно может не завершиться?
Хочется линк на обсуждение, очень интересно.

Как может крашиться база из-за какого-то завершения? Базе должно быть пофиг на всё это, для того её и используют, durability и всё такое.

Почему это не класть? А куда её класть? Я вот разрабатываю приложение, которое работает с базой и где мне её брать? Себе на локалхост ставить что-ли? С докером самое то — одной командой запустил, одной командой грохнул, в системе ноль мусора.

Почему это не класть? А куда её класть?

Куда хочешь, туда и клади. Докер не умеет в персистентность. Более того, он и не планировал ее уметь никогда, это фича. Все, что ты засунул в докер, может подохнуть в любой момент, а точнее - с ближайшим рестартом контейнера ты получишь девственно чистый контейнер.

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

Как может крашиться база из-за какого-то завершения?

Нажмите несколько раз резет на компе с постоянно пишущей субд, потом нам расскажите почему. Кстати это отдельно относиться к блокировшикам, они больше страдают.

Берите mariadb, у нее интересней функционал(движки, скорость) и она входит во все дистрибытивы линукс

Mysql же клепается Ораклом и изза этого в опенсорсе предпочитают с ним не связываться

Докер не умеет в персистентность.

https://docs.docker.com/engine/admin/volumes/volumes

Куда хочешь, туда и клади. Докер не умеет в персистентность.

Умеет.

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

Это не так. Если запускать контейнер через docker, есть volumes. Если запускать через docker-compose, то там всё сохраняется.

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

А технические доводы есть?

Нажмите несколько раз резет на компе с постоянно пишущей субд, потом нам расскажите почему. Кстати это отдельно относиться к блокировшикам, они больше страдают.

Нажимал много раз, ничего не было. Весь смысл ACID СУБД в том, чтобы данные не терялись при любых условиях кроме нерабочего оборудования.

Вот это аргументация. Молодец.

Как может крашиться база из-за какого-то завершения?

Очень просто: 1. хранилище на которое пишет база может не обеспечивать durability, не работающий fsync например 2. можно отключить durability в самой базе для скорости 3. можно создать не дюрабильные таблицы, они автоматически очищаются при аварийном завершении

С postgresql просто в одном из тредов было замечено, что при завершении контейнера не успевает завершаться сам сервис postgres.

Значит постгрес косорыло докеризовали. При запуске такого добра нужно в стартовом скрипте SIGTERM и SIGKILL перехватывать. В случае грамотно докеризованной БД её раньше времени может только OOM-killer прибить. Опять таки база с данными в докеровском volum-е - дно. Что её более-менее не стрёмно запустить в докере тебе нужна будет система оркестрации контейнеров и реально хорошая по IO СХД. С другой стороны нагруженной базе на дедике самое место. Я сталкивался с тем, что даже в виртуалке паршиво было и пришлось на выделенный сервер ехать. Так если тебе твое ТЗ позволяет использовать БД в докере может тебе вообще реляционка не нужна?

Волюмы это не персистентность, они находятся за пределами контейнера.

А технические доводы есть?

Есть опыт множества людей, и есть рекомендации самих разработчиков докера так не делать. Но если ты хипстер-назло-мамке-уши-отморожу, то конкретно тебе я разрешаю хранить данные внутри контейнера, чтобы естественный отбор сработал.

Создание БД PostgreSQL внутри Docker-образа подробно описано в документации.

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

fsync часто даёт выигрыш в скорости, это может привести к неисправимой порче.

Есть опыт множества людей

Скинь ссылки на опыт. Интересно.

Из-за рестарта данные не теряются. Данные поетряются если ты контейнер удалишь.

SIGKILL перехватывать.

А еще можно уворачиваться от пуль. Процесс не может обработать SIGKILL, не получает.

Опять таки база с данными в докеровском volum-е - дно.

Почему?

тебе нужна будет система оркестрации контейнеров

Она поможет работе I/O?

если тебе твое ТЗ позволяет использовать БД в докере может тебе вообще реляционка не нужна?

Конечно, может ему column oriented нужна. Verticа в контейнере лучше работает?

Я знаю как можно убить базу оракла (и думаю не только её одну), пару раз часы туда сюда передвинуть и привет... ORA-XXXXXX.

Вот ответ в том треде был.

PostgreSQL + Docker + многоядерный процессор (комментарий)

У меня было нечто подобное.

https://habrahabr.ru/post/332450/

А еще можно уворачиваться от пуль. Процесс не может обработать SIGKILL, не получает.

Вот ссылка на официальную доку: https://docs.docker.com/engine/reference/commandline/stop/#extended-description

The main process inside the container will receive SIGTERM, and after a grace period, SIGKILL.

Перехватывать SIGKILL нужно на случай если за вот этот «a grace period» постгрес не успеет нормально завершить свою работу. Если главный процесс постгреса и так SIGKILL игнорирует и пытается завершиться корректно, то я был бы тебе признателен за ссылку на постгресовскую доку.

Почему?

По личным субъективным наблюдениям около 10-12% IOPS-ов overlayfs сжирает. Мне этого даже в дев-средах жалко. Есть риск регрессионное тестирование не пройти. :) Хотя если бы наша софтварь даже в таких условиях нагрузку бы выдержала было бы круто. Но увы.

Она поможет работе I/O?

Она поможет подмонтировать в контейнер это самое СХД. Хотя если у тебя один хост с докером то можно монтировать СХД на хост, а потом хостовой путь - в контейнер.

Конечно, может ему column oriented нужна. Verticа в контейнере

лучше работает?

А разве column oriented это NoSQL? Я имел ввиду, что если ОП-у не страшно часть транзакций потерять (ИМХО в докере вероятность потерять часть транзакционного лога выше, чем если у тебя СУБД на дедике и есть резервный дедик с потоковой репликацией мастера), то может ну её вообще эту реляционку с сильной транзакционностью?

Ой лол. А ты мой пост откопал. :)

Реляционки они вообще довольно нежные на самом деле. Там не то, что часами. Там быдло-запросом можно деградировать производительность так, что оно уже рестарта потребует для нормальной работы.

Перехватывать SIGKILL

Процесс которому отослан SIGKILL перехватить и обработать сигнал не может. Ядро убьет процесс без предупреждений. Разе только в докере есть возможность сделать свой обработчик который отработает после «grace pariod», до того как docker пошлет SIGKILL.

По личным субъективным наблюдениям около 10-12% IOPS-ов overlayfs сжирает.

Это интересно. Почитаем.

А разве column oriented это NoSQL?

Да, там sql.

то может ну её вообще эту реляционку с сильной транзакционностью?

Я думаю, что реляционная база часто не столько ради acid берется. Много может быть причин: удобно, есть инструменты, данные отлично ложатся на реляционную модель, как например куча разных множеств и постоянные выборки с пересечениями между ними. Не все данные подходят к document oriented модели.

Если главный процесс постгреса и так SIGKILL игнорирует и пытается завершиться корректно, то я был бы тебе признателен за ссылку на постгресовскую доку.

http://turnoff.us/geek/dont-sigkill-2/ ;)

достаточно чтобы база лежала как отдельный volume

я автор этой статьи. Там нет ничего про volumes.

Опять таки база с данными в докеровском volum-е - дно.

Почему?

По личным субъективным наблюдениям около 10-12% IOPS-ов overlayfs сжирает.

Я не нахожу информации о том, что volume как-то связан с overlayfs. Зато по ссылке написанно:

A data volume is a directory or file in the Docker host’s filesystem that is mounted directly into a container. Data volumes are not controlled by the storage driver. Reads and writes to data volumes bypass the storage driver and operate at native host speeds.

Т.е. запись в volume осуществляется прямо на диск в хост системе без каких либо прослоек и потерь в I/O

я автор этой статьи

Значит тебя перевели на русский. А если серьезно, как можно наедятся на хоть какую либо стабильность с установкой/обновлением докера или установке/обновлении системы? Это написано по ссылке. Никогда не видел чтоб кто-то в проектах допускал автоапгрейд где либо.

Вот моя личная история, про минорный апгрейд СУБД, кажись postgres 8.x, минорное (!) обновление принесло новую точность датам. До обновления даты не хранили миллисекунды, а после стали. Бизнес логика содержала запросы на обновления с проверкой в условиях DATE=NEWDATE, ранее NEWDATE округлялась базой, а потом перестало, условие начало срабатывать не так как планировалось и все бизнес данные оказались испорчены.

в смысле, я делал перевод)

ну в dev режиме то можно делать автоапгрейд? Апгрейднулся - протестировал. Может быть, «оно само» заработает, и никаких действий вообще не потребуется

я понял) Но вопрос про штабильность остался. Есть ли смельчаки которые готовы делать апгрейды без создания тикета на багтрекере и тестирования?

Ты не автор, ты переводчик :)
А ТС хочет не волюмы, а прямо в контейнере, на что я ему и указал - не надо так делать.

Может быть, «оно само» заработает, и никаких действий вообще не потребуется

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

RAID контроллер с парой гиг кэша и с батарейкой. Если он накроется, то придется доставать бэкап, даже если есть запасной.

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

если у тебя всего 1 база - то это еще обсуждаемо. А если у тебя какой-нибудь Hazelcast или Apache Ignite с 2 тысячами виртуальных серверов в одном кластере, и всегда какая-то часть типа 10% куда-то мигрирует или лежит или поднимается, у тебя есть серьезные вопросы как этим управлять

а некисло ты от БД и docker volumes перепрыгнул к in-memory базам, при чем не просто к in-memory базам, а java-базам, которые в контейнере запускать на 7 или 8 жабе - ад и Израиль

что поделаешь, на предыдущей работе мы именно этим и занимались - писали управлялки кластером на 2000-20000 нод для джавовских гибридных баз (in-memory + хранилище на диске). Правда, совершенно всё самописное, включая базу данных.

Hyperconvergence является предметной областью и задачей, жизненно необходимой. А не вопросом обсуждения нужности :-) То есть, базы данных и их файловые хранилища так или иначе будут виртуализованы, это не вопрос. Вопрос в том, что для этого есть лучше Docker.

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

И если кто-то говорит, что в этой схеме Докер не подходит, то давайте сразу предлагать - что подходит вместо него, уже существует, бесплатно доступно в опенсорце и так далее

кококо, hazelcast, 20000 нод - это ты на конференциях перед пацанами понтоваться будешь. ты расскажи какой мне профит от докеризации/контейнеризации постгреса либо того же мускуля? в ОП никакого in-memory не было от слова совсем

и в хазле, и в игнайте, можно хранить персистентные данные. В том числе, в качестве платформы хранения выбрав реляционную базу. У хазла где-то на офсайте есть пример использования HSQLDB для этого. Но можно и постгрес. И даже мускуль, если ты камикадзе.

дальше сам :)

олсо, даже если там голый постгрес, то, учитывая как «отлично» работают мейнстримные постгресовые решения для кластеринга, или чудовищные велосипеды, и уже на паре десятков виртуалок у тебя наверняка появятся некоторые консёрны :)