Комментарии 25
В postgres 9.1 уже есть встроенный механизм потоковой репликации, и вполне можно обойтись без bucardo.
И если неошибаюсь на слейве RO при этом автоматом
И если неошибаюсь на слейве RO при этом автоматом
Вы ошибаетесь. Сейчас потоковая репликация в postgres 9.1 не умеет многое из того, что умеет вышеописанная связка. Так что статья очень полезная, автору спасибо.
Postgres + pgpool 2 же, хотя у меня еще и pgbouncer
Последний раз когда я крутил pgpool-2, он не умел передавать параметры в запросы серверу. Он умел их только подставлять. Со всеми вытекающими. После того, как я продемонстрировал руководству SQL Injection в таком варианте, от pgpool-2 пришлось отказаться. Хотя, сам по себе софт неплохой. И как только он научится работать с параметрами в postgresql 9+, можно будет рассмотреть вопрос о возвращении к нему.
Кроме того, один из существенных недостатков потоковой репликации postgres 9+ в том, что в случае сбоя мастера, невозможно слэйвы подключить к новому мастеру без полной их перезаливки (в случае более чем одного слэйва).
Кроме того, один из существенных недостатков потоковой репликации postgres 9+ в том, что в случае сбоя мастера, невозможно слэйвы подключить к новому мастеру без полной их перезаливки (в случае более чем одного слэйва).
А можете SQL Injection нам тоже продемонстрировать? Интересно :)
Самому было интересно. :)
В общем, насколько я помню, я там в выражение типа «delete from table1 where id = ?» в качестве параметра подставлял что-то вроде вот такого: «1 OR 1; --». В этом случае все что после "--" (например, там могли быть кавычки, в которые убирается параметр при вставке через pgpool-2) при выполнении SQL воспринималось как комментарий и выражение удаляло все записи в таблице.
В общем, насколько я помню, я там в выражение типа «delete from table1 where id = ?» в качестве параметра подставлял что-то вроде вот такого: «1 OR 1; --». В этом случае все что после "--" (например, там могли быть кавычки, в которые убирается параметр при вставке через pgpool-2) при выполнении SQL воспринималось как комментарий и выражение удаляло все записи в таблице.
Что-то больно просто получается. Получается pgpool-2 вообще параметры не экранирует?
До версии postgres 8 включительно, там использовалась нормальная работа с параметрами. Думаю, надо просто не использовать такой режим (это в конфиге задается). Тогда pgpool нормально передает параметры на сервер. Когда я его крутил (чуть меньше года назад), он не умел этого делать для postgres 9 и приходилось использовать именно подстановку через pgpool. Возможно, сейчас уже умеет — просто не интересовался.
У pgbouncer возникала проблема. Боунсер имеет свою базу пользователей никак автоматически не синхронизируемую с постгресовой (только руками), что является неудобствами в перспективе.
+ по сути своей боунсер простой и удобный пулер, но без файловера. И раз уж все равно пользоваться PgPool-II, то зачем городить еще и bouncer, когда PgPool выполняет его функции.
+ по сути своей боунсер простой и удобный пулер, но без файловера. И раз уж все равно пользоваться PgPool-II, то зачем городить еще и bouncer, когда PgPool выполняет его функции.
Ну да есть такое, но у меня небольшое и конечное количество баз и пользователей, поэтому особых проблем это несоставляет.
Мы пробовали использовать только pgpool-II у него пулер послабее чем в баунсере, поэтому пришлось вот такой огород городить…
ну и за несколько лет работы баунсер работает гораздо стабильнее чем pgpool-II
Мы пробовали использовать только pgpool-II у него пулер послабее чем в баунсере, поэтому пришлось вот такой огород городить…
ну и за несколько лет работы баунсер работает гораздо стабильнее чем pgpool-II
Может я чего-то не знаю… На тему синхронизации пользователей БД: в pgbouncer.ini есть крутилка auth_file, которой можно скормить "/var/lib/postgresql//main/global/pg_auth" и auth_type=md5. У меня так и работает сейчас, может есть какие-то противопоказания?
Как вариант можно скриптиком по крону ходить в базу, доставать пользователей и сохранять их в auth_file
Встроенный механизм, как я поняла, направлен на синхронную репликацию.
По факту со стороны клиента и pgpool'а со слейва только чтение, со стороны bucardo — запись.
А на самом деле, если даже просто консольным psql подключится к слейву — то запись дозволена, что может создавать проблемы (ибо репликация one-way).
Во всяком случае я не нашла конкретных настроек по переключению прав.
По факту со стороны клиента и pgpool'а со слейва только чтение, со стороны bucardo — запись.
А на самом деле, если даже просто консольным psql подключится к слейву — то запись дозволена, что может создавать проблемы (ибо репликация one-way).
Во всяком случае я не нашла конкретных настроек по переключению прав.
Встроенный механизм асинхронный, там просто доливаются wal логи.
хм по поводу подключения напрямую проверил:
create database test;
ERROR: cannot execute CREATE DATABASE in a read-only transaction
Вот с такими параметрами запускается слейв
standby_mode = 'on'
primary_conninfo = 'host=$HOSTNAME user=postgres'
trigger_file = '/tmp/trigger_file0
хм по поводу подключения напрямую проверил:
create database test;
ERROR: cannot execute CREATE DATABASE in a read-only transaction
Вот с такими параметрами запускается слейв
standby_mode = 'on'
primary_conninfo = 'host=$HOSTNAME user=postgres'
trigger_file = '/tmp/trigger_file0
По умолчанию он асинхронный, синхронность надо включать отдельно параметром synchronous_standby_names. В качестве значения параметра — хостнеймы или application_name (указывается в recovery.conf) слэйвов.
Грабли на которые я напоролся при синхронной репликации: если слэйв один и он упал, то мастер на все запросы записи в базу тупо не будет отвечать ибо он ждёт когда эти данные не запишутся уже лежащий слейв. synchronous_standby_names можно менять на лету и отключить репликацию, но уже «висящие» запросы придётся как-то убивать.
Грабли на которые я напоролся при синхронной репликации: если слэйв один и он упал, то мастер на все запросы записи в базу тупо не будет отвечать ибо он ждёт когда эти данные не запишутся уже лежащий слейв. synchronous_standby_names можно менять на лету и отключить репликацию, но уже «висящие» запросы придётся как-то убивать.
Грабли на которые я напоролся при синхронной репликации: если слэйв один и он упал, то мастер на все запросы записи в базу тупо не будет отвечать ибо он ждёт когда эти данные не запишутся уже лежащий слейв. synchronous_standby_names можно менять на лету и отключить репликацию, но уже «висящие» запросы придётся как-то убивать.
Вот поэтому синхронную не рассматривали. Потому что большие клиентские запросы и такие подвисающие запросы недопустимы
При синтетических тестах (pgbench) pgpool-II с двумя нодами (балансинг + полер) проигрывал pgbouncer'у на одной, даже более того: pgpool-II проигрывал чистому postgre без пулера соединений. Вывод: использовать pgpool-II для балансинга+пулер следует только в случае очень тяжёлых запросов, иначе только теряем в производительности.
НЛО прилетело и опубликовало эту надпись здесь
С Мускулем приходилось сталкиваться, но глубоко не лезла. Но отсутствие, напрмер, частичных индексов и корявость составных вызывали кровавые слезы ))
Да и вообще MySql все же расчитан на не очень большие объемы данных. После постгреса оптимизировать мускульную базу без права изменения структур получалось очень тяжело.
Да и вообще MySql все же расчитан на не очень большие объемы данных. После постгреса оптимизировать мускульную базу без права изменения структур получалось очень тяжело.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
PostgreSQL — Asynchronous Replication + Pooling + Failover