Pull to refresh

Comments 16

А можно ли иметь несколько standby-баз, накатывать логи сразу на все и делать select из них, оставив для основной базы только обработку insert\update?
По ссылке:

The data on the standby takes some time to arrive from the primary server so there will be a measurable delay between primary and standby. Running the same query nearly simultaneously on both primary and standby might therefore return differing results.
наличие лага для любой асинхронной репликации это нормально и не смертельно. вопрос про то можно ли держать несколько реплик с одним мастером.
да можно:
первые два абзаца: developer.postgresql.org/pgdocs/postgres/warm-standby.html
только надо иметь ввиду что реплики могут отставать от мастера, и некоторые запросы для которых актуальность данных критична всё равно придётся делать на мастере
А тем временем в MySQL селекты из SLAVE баз никто не запрещал уже лет 100500. Более того — некоторый софт умеет активно эту функциональность (например поиск в vBulletin делается со SLAVE при его наличии), что впрочем никогда не мешал независимым разаботчикам это делать тоже.
А теперь это может делать и PostgreSQL. Если вас смущало отсутствие этой возможности, то теперь вам ни что не помешает посмотреть и попробовать эту отличную RDBMS.
при использовании Slony SELECT-ы тоже отлично работают
Только slony работает (или всё же работают?, «слоны» ведь) на триггерах, заметно ударяя по производительности insertов. А тут всё через wal-логи, я так понял.
Круто, буду попробовать.
ну да, лаг в единицы секунд у слонов это как нечего делать.
будем ждать пока WAL-репликацию до ума доведут, там пока не всё гладко (оно в разработке, это понятно).
слоны очень приятны своей надёжностью и гибкостью посмотрим что тут будет.
кстати на саму производительность вставки slony влияет не очень сильно.
я правильно понял что ты говоришь о времени через которое эти данные появятся на реплике?
У меня получилось уменьшение скорости запроса (именно запроса, не репликации) где-то на 15%.
Это не так плохо, как какой-нибудь триггерный rubyrep (рост в 4 раза на тестовой десктопной машине, измерено с помощью `time pgbench -t 10000`), но всё же чувствительно. При этом rsync writeahead-логов, понятно, никакой сопоставимой дополнительной нагрузки не даёт (для случай warm standby я это также пробовал).
И в Oracle тоже. Дорогой тролль, новость не об этом.
Я в общем то и не пытался кого то троллить, хоть и люблю это делать. Просто забавно бывает читать такие восторженные записи о постгри, его «новых» возможностях и т.п. когда такие «стремные и отстойные» по словам фанатов постгри, как MySQL умели это чуть ли не с рождения
Что-то есть в MySQL чего нет в PostgeSQL, что-то есть в PostgeSQL что появилось в MySQL не так давно. Часть вещей ни когда не будет иметь аналогов в другой СУБД. Правильно говорят, не о том речь.
Люди радуются новым возможностям, потому что используют его.
Warm standby появился в постгресе раньше 8.4, по крайней мере у нас он прекрасно работает на 8.3.

Что касается hot standby, то его хотели добавить в 8.4, но не успели, и перенесли на 8.5, и (о чудо!) это случилось, оно будет: пруф

А ещё уже закомичен streaming replication (пруф), который будет постоянно переносить логи и не прийдётся скриптами копировать большие куски раз в несколько минут.

Полноценная master-slave репликация уже не за горами. Ура! :)
Sign up to leave a comment.

Articles