Комментарии 9
Увидев про сложный сценарий с базой данных в Докере, зашел прочитать о само интересном, куда и как вы пишите данные базы данных и что происходит при релокации контейнеров. Но не увидел…
Спасибо за комментарий. Давайте попробуем разобраться.
Собственно за данные отвечает сама БД, именно она решает куда писать данные, точнее это определяется переменной окружения контейнера PGDATA (которую мы указываем при создании контейнера). Далее, мы подключаем к контейнеру volume с папкой на хосте (снаружи контейнера), где данные будут хранится на самом деле, то есть не внутри контейнера.
Этот вопрос я не совсем понял. Но в любом случае, данные БД никуда не релоцируются, они сохраняются даже при полном уничтожении контейнера (благодаря volume). А физический перенос данных при добавлении нового slave производится при помощи стандартной утилиты pg_basebackup, которая производит всю необходимую работу по переносу данных с одного сервера на другой.
куда и как вы пишите данные базы данных
Собственно за данные отвечает сама БД, именно она решает куда писать данные, точнее это определяется переменной окружения контейнера PGDATA (которую мы указываем при создании контейнера). Далее, мы подключаем к контейнеру volume с папкой на хосте (снаружи контейнера), где данные будут хранится на самом деле, то есть не внутри контейнера.
и что происходит при релокации контейнеров
Этот вопрос я не совсем понял. Но в любом случае, данные БД никуда не релоцируются, они сохраняются даже при полном уничтожении контейнера (благодаря volume). А физический перенос данных при добавлении нового slave производится при помощи стандартной утилиты pg_basebackup, которая производит всю необходимую работу по переносу данных с одного сервера на другой.
В «нормальном»* кластере совершенно не хочется полагаться на доступнось какого-то определенного нода и знать его в лицо…
Если работать с контенерами то очень быстро имеет смысл не полагаться на топологию кластера (покраней мере на конкретные ноды)
Видимо в вашем примере вы полагаетесь на доступность конкретного хоста/нода/виртульной машины.
Но представьте боевой кластер с 10 или 100 машинами… с нормальным скедьюлером.
Ваш контейнер пишет данные через volume в хост «номер 7» потому что скедьюлер его там стартанул…
Так что происходит с вашими данными если машина номер 7 не отвечает минут 5 и контенер с мастером стартнул где-то в на машине 99?
Что происходит если машина не должна возвратится?
В этом то весь интерес… при поднятии каких-либо баз данных в «нормальном» контеннерном класстер, очень сильно не хочется собирать данные на ких-то хостах…
Хотя может это и просто по началу…
Если работать с контенерами то очень быстро имеет смысл не полагаться на топологию кластера (покраней мере на конкретные ноды)
Видимо в вашем примере вы полагаетесь на доступность конкретного хоста/нода/виртульной машины.
Но представьте боевой кластер с 10 или 100 машинами… с нормальным скедьюлером.
Ваш контейнер пишет данные через volume в хост «номер 7» потому что скедьюлер его там стартанул…
Так что происходит с вашими данными если машина номер 7 не отвечает минут 5 и контенер с мастером стартнул где-то в на машине 99?
Что происходит если машина не должна возвратится?
В этом то весь интерес… при поднятии каких-либо баз данных в «нормальном» контеннерном класстер, очень сильно не хочется собирать данные на ких-то хостах…
Хотя может это и просто по началу…
Вы правы насчет контейнеров, которые не хранят состояние. Работая с такими контейнерами действительно не хочется полагаться на работоспособность одного из сотни, или даже тысячи хостов. И очень здорово здесь может помочь Swarm. Скажу немного заранее, но уже сейчас в соответствующей ветке, где идет разработка поддержки режима Swarm, реализована возможность безболезненно пропускать отвалившиеся и неработающие хосты. По сути, для работы Fabricio нужен в этом случае только активный менеджер, отказоустойчивость которого гарантируется роем (Swarm).
Но в случае же с БД хранится не просто состояние, а целая база, которая может насчитывать терабайты и терабайты данных. Перекидывать такой объем данных даже в случае отказа — весьма накладное дело. Именно поэтому количество хостов БД в любых конфигурациях, как правило, строго ограничено и не превышает в большинстве случаев 10-ти серверов (хотя возможны и другие варианты, но не с реляционными БД).
Подводя итог, в Fabricio контейнеры работают в «strict» режиме, то есть любая ошибка с невозможностью поднять контейнер рассматривается как фатальная и запрещающая дальнейшую работу (до тех пор, пока ошибка не будет исправлена). Это же касается и master-slave конфигурации, для которой это актуальнее даже в бОльшей степени, потому что цена ошибки в таких конфигурациях стоит очень дорого для того, чтобы полностью полагаться на автоматику.
Но в случае же с БД хранится не просто состояние, а целая база, которая может насчитывать терабайты и терабайты данных. Перекидывать такой объем данных даже в случае отказа — весьма накладное дело. Именно поэтому количество хостов БД в любых конфигурациях, как правило, строго ограничено и не превышает в большинстве случаев 10-ти серверов (хотя возможны и другие варианты, но не с реляционными БД).
Подводя итог, в Fabricio контейнеры работают в «strict» режиме, то есть любая ошибка с невозможностью поднять контейнер рассматривается как фатальная и запрещающая дальнейшую работу (до тех пор, пока ошибка не будет исправлена). Это же касается и master-slave конфигурации, для которой это актуальнее даже в бОльшей степени, потому что цена ошибки в таких конфигурациях стоит очень дорого для того, чтобы полностью полагаться на автоматику.
Но в случае же с БД хранится не просто состояние, а целая база, которая может насчитывать терабайты и терабайты данных. Перекидывать такой объем данных даже в случае отказа — весьма накладное дело. Именно поэтому количество хостов БД в любых конфигурациях, как правило, строго ограничено и не превышает в большинстве случаев 10-ти серверов (хотя возможны и другие варианты, но не с реляционными БД).
Ну в том то и дело… Есть ли смысл вообще базу данных в докер пихать…
мы подключаем к контейнеру volume с папкой на хосте
Чего-то каша какая-то. В Docker есть volume, а есть папка на хосте (bind).
Первое выглядит так: -v abc:/data, второе так: ./abc:/data
Полный лист volum'ов вы можете посмотреть в docker volume ls. Никаких папок хоста там нет :-)
куда и как вы пишите данные базы данных и что происходит при релокации контейнеров
Базу данных, как вы сами понимаете, в контейнере не держат. Кроме стандартных способов volume/bind существует PersistentVolume. В кратце: это когда в кластер контейнеров вы монтируете кластер данных (все вместе это называется, если не путаю, StatefulSet).
Но одним докером вы уже не обойдетесь. Нужен K8s. Полный список поддерживаемых кластеров данных есть тут.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Docker: деплой master-slave конфигурации PostgreSQL