девелоперами и тестерами.
Нынешняя схема такая: тестер/девелопер, когда ему надо, идёт в Портейнер и деплоит стек с той бд, которая ему нужна. Стек поднимается, тестовая бд ресторится из дампа. Всё работает, всё отлично.
Но есть момент: некоторые тестовые бд довольно большие. Снапшот одной из таких неприятных за последние две недели весит 60 гиг. В условиях портейнера это довольно долго восстанавливается — может до часа с индексами.
Я придумал стартовать по ночам контейнеры с постгресом, чтобы бд там восстанавливалась, потом я этот контейнер просто коммичу в новый образ (с паузой исходного) и тушу оба. Таким образом, тестеры/девелоперы могли бы просто мгновенно поднимать стек с любой бд, вне зависимости от её объёма, просто запрашивая контейнер с тегом нужной бд.
Однако, возникла неприятность: Когда я поднимаю контейнер с имеющейся в нём БД, то постгрес не видит тейблспейса, куда была эта бд восстановлена. Куда копать?
Отвечайте, плз, реплаем или в личку, чтобы я не потерял ваш ответ в общем потоке.
Парни, на этот вопрос всё ещё нужны ответы/идеи. В логах постгреса, стартующего из нового образа тишина: кроме стандартных сообщений «я запустился и готов к работе» ничего нет, а тейблспейс потерялся. :(
Основная идея -- вы запускаете какую-то херню, а не тот образ, в котором добавили tablespace.
Нет, таки я запускаю правильный образ. Просто постгрес запускается как будто с нуля.
Ну, тот значит тот, что я могу поделать. PS postgres, во-первых не можэт "случайно" потерять запись в pg_tablespace а во-вторых -- думаю, упадёт при первом обращении к таблицэ из этого tablespace если запись -- будет, а с симлинком в $PGDATA/pg_tblspc будут проблемы.
Так, спасибо за мысль. Образ же на основе дефолтного пг. То есть он уверен, что запускается пустой и инициализируется соответственно. Надо заоверрайдить с чего всё начинается
если база для тестера нужна одна на экземпляр постгреса в контейнере то запакуйте data_directory целиком, с уже готовой базой. т.е. где у вас делается восстановление БД тормозите постгрес и заливаете поверх data_diretcory уже готовую с данными. распаковывать можно tar + pigz, что бы быстрее было.
Там уже сложный процесс. Там в процессе бэкапа продовых баз делается укороченый снапшот, из которого вычищается всякое что тестерам не положено и потом просто целиком дампится, чтобы разворачиваться на разных тестах. Данные снапшоты используются не только живыми людьми, но и всякими автотестами.
ну так сделали снапшот, потом пустой постгрес поставили, снапшот туда развернули, это делается 1 раз, можно применить всякие хитрости типа добавления индексов потом, после влива данных. потом постгрес гасите и делаете архив data_directory. Его уже тестерам раздаете. Т.е. в месте "потом просто целиком дампится" надо залить это в пустой постргерс и запаковать data_directory.
я по сути так и делаю: поднимаю дефолтный контейнер с пг и восстанавливаю в него из дампа короткую бд. Я, кажется, понял в чём косяк. Ща колдую над этим.
В общем, надо было, как обычно, правильно задать вопрос гуглу. Если кому интересно, то вот решение: https://stackoverflow.com/questions/27377876/docker-postgres-with-initial-data-is-not-persisted-over-commits Во втором ответе.
Обсуждают сегодня