Репликация миграций в PostgreSQL
Alexander Oryol
Как я понял, самое частое решение для репликации - Slony-I. Но как
быть с миграциями?
Кто как решает?
--
Alexander Oryol <eagle...@gmail.com>
Max Lapshin
Всем привет.
Как я понял, самое частое решение для репликации - Slony-I. Но как
быть с миграциями?
Кто как решает?
Ivan Evtuhovich
Попробуй Londiste, они гораздо проще в настройке. Мы два раза
переезжали с сервера на сервер, использую Londiste.
Londiste написан компанией skype на базе их реализации очередей PgQ.
Насчет миграций -- сложнее, стандартного решения нет.
2009/3/25 Max Lapshin <max.l...@gmail.com>:
eagleas
и копию кода на слейвах?
Именно этого и хотелось избежать.
On 25 мар, 18:03, Max Lapshin <max.laps...@gmail.com> wrote:
> 2009/3/25 Alexander Oryol <eagle.a...@gmail.com>
--
Alexander Oryol <eagle...@gmail.com>
Max Lapshin
Т.е. никуда не денешься от того чтобы держать деплой-юзера, ruby/gems
и копию кода на слейвах?
Именно этого и хотелось избежать.
Ivan Evtuhovich
коннектиться ко всем нужным базам и прогонять миграции.
В любом случае, придется что-то дописывать, почему бы не дописать в таком ключе.
2009/3/25 eagleas <eagle...@gmail.com>:
Max Lapshin
Вообще, копию кода можно держать только на одном сервере. А оттуда
коннектиться ко всем нужным базам и прогонять миграции.
В любом случае, придется что-то дописывать, почему бы не дописать в таком ключе.
Alexander Oryol
> Вообще, копию кода можно держать только на одном сервере. А оттуда
> коннектиться ко всем нужным базам и прогонять миграции.
>
> В любом случае, придется что-то дописывать, почему бы не дописать в таком ключе.
Вот именно это я и спрашивал, может кто-то уже делал?
И пока у меня не складывается четкой картинки как рецептами капистрано
это сделать.
> 2009/3/25 eagleas <eagle.a...@gmail.com>:
> > Т.е. никуда не денешься от того чтобы держать деплой-юзера, ruby/gems
> > и копию кода на слейвах?
> > Именно этого и хотелось избежать.
--
Alexander Oryol <eagle...@gmail.com>
Nikolay Grebnev
Max Lapshin
Alexander Oryol
> Привет.
>
> Попробуй Londiste, они гораздо проще в настройке. Мы два раза
> переезжали с сервера на сервер, использую Londiste.
>
> Londiste написан компанией skype на базе их реализации очередей PgQ.
Цитата из http://postgresmen.ru/articles/view/25 про Londiste:
"К недостаткам можно отнести:
* отсутствие поддержки sequence делает невозможным поддержание
failover-сервера актуальным (для этой цели нужно использовать WalMgr)"
Что имеется ввиду под "отсутствие поддержки sequence" ?
>
> Насчет миграций -- сложнее, стандартного решения нет.
>
> 2009/3/25 Max Lapshin <max.laps...@gmail.com>:
>
>
>
> > 2009/3/25 Alexander Oryol <eagle.a...@gmail.com>
>
> >> Всем привет.
>
> >> Как я понял, самое частое решение для репликации - Slony-I. Но как
> >> быть с миграциями?
> >> Кто как решает?
>
> > У меня продакшн запусков постгреса сейчас нет, но как я понял, надо что-то
> > типа такого:
> > сделать что бы cap deploy:migrate прокатывался на всех ролях :db и добавить
> > все слейвы в :db.
--
Alexander Oryol <eagle...@gmail.com>
Alexander Oryol
О, спасибо. Сегодня тестим с :roles, завтра попробуем это решение.
--
Alexander Oryol <eagle...@gmail.com>
Ivan Evtuhovich
В той же статье внизу:
Apr 2007
Как я понимаю, раньше не реплицировались sequences, а теперь с этим
всё в порядке.
Более подробно про Londiste рассказать не могу, так как оба раза
репликацию настраивал мой коллега. В планах у нас поднять
failover-кластер как раз с использованием Londiste.
2009/3/25 Alexander Oryol <eagle...@gmail.com>:
andrey....@gmail.com
Все делается на master-сервере, на slave надо будет только развернуть
свежий дамп для ускорения процесса начальной синхронизации баз.
1. Ставим последние skytools (http://pgfoundry.org/projects/skytools/)
2. Создаем файл ticker.ini (конфиг для pgq тикера)
[pgqadm]
job_name = pgqadm_master_db
db = dbname=master_db user=pgsql
# how often to run maintenance [seconds]
maint_delay = 600
# how often to check for activity [seconds]
loop_delay = 0.1
logfile = /usr/db/pgsql/data/pg_log/%(job_name)s.log
pidfile = /usr/db/pgsql/data/pg_log/%(job_name)s.pid
3. Создаем файл replic.ini (конфиг для londiste)
[londiste]
job_name = myproject_master_db_to_slave
provider_db = dbname=master_db
subscriber_db = dbname=slave_db host=slave_host
# it will be used as sql ident so no dots/spaces
pgq_queue_name = replika
logfile = /usr/db/pgsql/data/pg_log/%(job_name)s.log
pidfile = /usr/db/pgsql/data/pg_log/%(job_name)s.pid
3. Запускаем pgq-тикер:
pgqadm.py ticker.ini install
pgqadm.py ticker.ini ticker -d
4. Разворачиваем дамп мастера на subscriber_db и запускаем репликацию:
pg_dump/pg_restore
londiste.py replic.ini provider install
londiste.py replic.ini subscriber install
londiste.py replic.ini replay -d
5. Указываем таблицы и последовательности для репликации:
londiste.py replic.ini provider add `echo "\dt" | psql -t master_db
pgsql | awk '{print $3}'`
londiste.py replic.ini provider add-seq `echo "\ds" | psql -t
master_db pgsql | awk '{print $3}'`
londiste.py replic.ini subscriber add `echo "\dt" | psql -t master_db
pgsql | awk '{print $3}'`
londiste.py replic.ini subscriber add-seq `echo "\ds" | psql -t
master_db pgsql | awk '{print $3}'`
6. Контролируем процесс
Смотрим состояние синхронизации таблиц:
londiste.py replic.ini subscriber tables
Следим за активностью londiste:
tail -f /usr/db/pgsql/data/pg_log/%(job_name)s.log
Примерно так :)
Nikolay Grebnev
Вопрос навскидку - А что такое "свежий дамп" . Как и когда его делать, если база постоянно обновляется???
andrey....@gmail.com
On Mar 28, 5:09 pm, Nikolay Grebnev <nikolaygreb...@gmail.com> wrote:
> Круто. Вам надо опубликовать это где-то. Первое вменяемое описание работы с
> londiste .
Спасибо за предложение, пожалуй стоит с посгресменами(postgresmen.ru)
обсудить.
> Вопрос навскидку - А что такое "свежий дамп" . Как и когда его делать, если
> база постоянно обновляется???
>
Это надо сделать один раз при настройке. После уже на таблицах master-
базы будут висеть триггеры,
которые будут сбрасывать изменения в pgq-очереди, а скрипт
londiste.py будет
реплицировать их в slave-базу.
Max Lapshin
Круто. Вам надо опубликовать это где-то. Первое вменяемое описание работы с londiste .
Вопрос навскидку - А что такое "свежий дамп" . Как и когда его делать, если база постоянно обновляется???
Nikolay Grebnev
http://pgsql.tapoueh.org/site/html/londiste/londiste.html
Где описание не совсем членоразденое. (может и нет, но тогда применения у себя по этому описанию я не усмотрел)
Max Lapshin
Несколько месяцев назад не было. Была ссылка на
http://pgsql.tapoueh.org/site/html/londiste/londiste.html
Где описание не совсем членоразденое. (может и нет, но тогда применения у себя по этому описанию я не усмотрел)
Alexander Oryol
Во-первых пришлось все же перепрыгнуть на Londiste, т.к. Slony-I лочит
реплицируемые таблицы на slave, и с этим ничего нельзя поделать, кроме
как оборачивать все миграции в "EXECUTE SCRIPT", что несерьезно.
On 25 мар, 20:26, Alexander Oryol <eagle.a...@gmail.com> wrote:
> On 25 мар, 19:04, Max Lapshin <max.laps...@gmail.com> wrote:
> > config/database.yml:
> > production:
> > ...
> > slave_1:
> > ...
> > slave_2:
> > ...
Это все так.
>
> > config/deploy.rb:
>
> > namespace :deploy do
> > desc "Task that run current migrations"
> > task :migrate, :roles => :db do
> > envs = %w(production slave1 slave2)
> > run "cd #{deploy_to} ; " + envs.map {|env| "RAILS_ENV=#{env} rake
> > db:migrate"}.join(";")
> > end
> > end
>
> > ну как-то так.
А это так:
namespace :deploy do
desc "Task that run current migrations"
task :migrate, :roles => :db do
migrate_target = fetch(:migrate_target, :latest)
directory = case migrate_target.to_sym
when :current then current_path
when :latest then current_release
else raise ArgumentError, "unknown migration target #
{migrate_target.inspect}"
end
version = ENV['VERSION'] ? "VERSION=#{ENV['VERSION']}" : ""
envs = ["#{stage}", "#{stage}_slave1"]
run "cd #{directory} && " + envs.map {|env| "(echo '==
environment: #{env} =='; RAILS_ENV=#{env} rake db:migrate #
{version})"}.join(' && ')
end
end
Мы используем capistrano multistage поэтому подмешана stage
переменная. Для того чтобы можно было указывать версию - протаскиваем
VERSION внутрь.
> О, спасибо. Сегодня тестим с :roles, завтра попробуем это решение.
Вариант с ролями оказался самый геморройный. Ну вот нафига на хосте
накотором только PostgreSQL - руби, рельсы, репозиторий проекта и все
внешние гемы к нему (да, про vendor/gems в курсе, туда просто не все
запихивается)...
А т.к. гемы подразумевают компиляцию - еще и gcc, gpp и прочая...
Осталась нерешенной одна проблема - после создания в миграции новой
таблицы нужно запускать от системного юзера postgres на хосте базы
команды:
londiste.py /etc/londiste_your_cluster_name.ini provider add new_table
londiste.py /etc/londiste_your_cluster_name.ini subscriber add
new_table
Соотв. нужно переопределять
ActiveRecord::ConnectionAdapters::SchemaStatements.create_table и еще
куча возни со входом на хост базы, sudoers и тд. Если кто-то решит -
сообщайте! :)
--
Alexander Oryol <eagle...@gmail.com>
Alexander Oryol
> Отчет :-)
>
> Во-первых пришлось все же перепрыгнуть на Londiste,
Еще несколько ньюансов.
0. Одной из миграций нужно execute "CREATE LANGUAGE plpgsql" / "DROP
LANGUAGE plpgsql", лучше самой первой.
1. Таблицу schema_migrations реплицировать не нужно, и добавлять в нее
primary key соответственно тоже.
2. Касаемо Londiste для CentOS. От первого лица:
"SkyTools есть в репозиториях постгреса для CentOS, но проблема
заключается что в этом пакете не включены модули дополнительные, а
именно Pgq_LowLevel. Поэтому сделал следующее:
СКачал последнюю версию skytools с сайта, сконфигурил, скомпилировал,
и взял оттуда лишь модули для питона Pgq_LowLevel, затем поставил пакет
( благо версии пакета в репозитории и модулей совпали) и скопировал
модули pgq_lowlevel.so, pgq_triggers.so, logtriga.so в /usr/lib/
pgsql/.
Всё дальше можно переходить к репликации."
Удачи!
--
Alexander Oryol <eagle...@gmail.com>
Max Lapshin
Alexander Oryol
> Да, ещё вопрос. Не спокойнее держать всё таки на второй машине hot-standby
> сервер рельс?
Мы к этому идем постепенно, про DRBD я уже писал, месяц в продакшне -
полет нормальный. Но базы то все равно должны быть on-line
реплицированы.
Полагаю, с т.з. расходования аппаратных ресурсов, эффективнее будет
выносить все базы данных на один хост на котором будет только
PostgreSQL и ничего больше. Если не прав - поправьте.
--
Alexander Oryol <eagle...@gmail.com>
Max Lapshin
Nikolay Grebnev
Полагаю, с т.з. расходования аппаратных ресурсов, эффективнее будет
выносить все базы данных на один хост на котором будет только
PostgreSQL и ничего больше. Если не прав - поправьте.
Мой опыт, что PostgreSQL в нагруженном виде вместе с кем-то еще одновременно на машине работает совершенно ужастно. Это когда база данных большая. Для маленьких баз на 1-2 гига скорее всего пофигу.
Alexander Oryol
> > Полагаю, с т.з. расходования аппаратных ресурсов, эффективнее будет
> > выносить все базы данных на один хост на котором будет только
> > PostgreSQL и ничего больше. Если не прав - поправьте.
> С точки зрения железа, которое ждет самого удобного момента, что бы сжечь
> все винты материнкой,
:-)
Вот для этого и пытаемся держать второй on-line реплицированный хост.
Кроме этого - ночные бэкапы на отдельный (в идеале) хост. Следующий
шаг видимо pgpool, для переключения автоматом на живую базу.
Может кстати решение с миграциями в виде плагина законтрибутить? Стоит
оно того, или мало кому это надо?
По уму бы это вынести в отдельный конфиг типа slaves.yml, т.к. у меня
лично дополнительные environments потянули за собой еще некоторые
правки в конфигах.
--
Alexander Oryol <eagle...@gmail.com>
Max Lapshin
Может кстати решение с миграциями в виде плагина законтрибутить? Стоит
оно того, или мало кому это надо?
По уму бы это вынести в отдельный конфиг типа slaves.yml, т.к. у меня
лично дополнительные environments потянули за собой еще некоторые
правки в конфигах.
Alexey Kovyrin
(mysql) ковыряться в носу :-)
Мускульная репликация (судя по этому треду) в сравнении с постресными
костылищаци - рай на земле!
P.S. Ага, флудопровокатор я :--)
2009/3/30 Max Lapshin <max.l...@gmail.com>:
--
Alexey Kovyrin
http://kovyrin.info/
Max Lapshin
Угу, читаю тред и офигеваю - и эти люди (постгрес) запрещают нам
(mysql) ковыряться в носу :-)
Мускульная репликация (судя по этому треду) в сравнении с постресными
костылищаци - рай на земле!
P.S. Ага, флудопровокатор я :--)
Alexey Kovyrin
отставания от мастера было больше недели. За сутки догнало без
каких-либо проблем :-)
2009/3/30 Max Lapshin <max.l...@gmail.com>:
--
Alexey Kovyrin
http://kovyrin.info/
Max Lapshin
Ы - на прошлой неделе поднимал слейв из старого бекапа - время
отставания от мастера было больше недели. За сутки догнало без
каких-либо проблем :-)