PostgreSQL

индекс
124,74

Физика высоких температур

Все уже наверняка обратили внимание, что в PostgreSQL 8.4 появился новый режим работы базы данных: Warm standby. При нём во время работы базы данных Write-Ahead логи (WAL) транслируются на подчинённую базу данных, на которой в реальном времени применяются, как если бы это происходило на основной системе. Поэтому, если основная база данных по какой-то причине (молния/торнадо/третья мировая война/другие стихийные бедствия) выйдет из строя, можно будет мгновенно переключиться на подчинённую базу данных (данные в которой будут достаточно актуальны по сравнению с основной базой) и использовать её дальше.
Но, к сожалению, «тёплый стэндбай» подразумевает, что на подчинённой системе непрерывно происходит процесс восстановления базы данных; из чего следует, что пока основная база жива, подчинённой базой пользоваться нельзя.
Если вы читаете хотя бы блог depesz (не говоря уже про коммит-логи), то вы уже знаете, к чему я веду; если же нет, то… 19-го декабря прошлого года в разрабатываемую версию PostgreSQL 8.5 была добавлена функциональность Hot standby. Теперь, при настройке репликации WAL, подчинённая база данных тоже может использоваться для запросов SELECT (и только SELECT, по понятным причинам). Если раньше второй сервер со второй базой данных простаивал в ожидании форс-мажора, и админу приходилось краснеть перед менеджерами при вопросах об эффективности использования оборудования — то теперь этот сервер, при правильном построении логики приложений, поможет разгрузить основную базу данных.
Подробности о функционировании Hot standby можно прочитать в соответствующей статье из документации разрабатываемой версии PostgreSQL.
+32
9 января 2010, 01:11
21

комментарии (16)

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

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.
+1
overPlumbum #
наличие лага для любой асинхронной репликации это нормально и не смертельно. вопрос про то можно ли держать несколько реплик с одним мастером.
0
overPlumbum #
да можно:
первые два абзаца: developer.postgresql.org/pgdocs/postgres/warm-standby.html
только надо иметь ввиду что реплики могут отставать от мастера, и некоторые запросы для которых актуальность данных критична всё равно придётся делать на мастере
–2
NickyX3 #
А тем временем в MySQL селекты из SLAVE баз никто не запрещал уже лет 100500. Более того — некоторый софт умеет активно эту функциональность (например поиск в vBulletin делается со SLAVE при его наличии), что впрочем никогда не мешал независимым разаботчикам это делать тоже.
0
insa #
А теперь это может делать и PostgreSQL. Если вас смущало отсутствие этой возможности, то теперь вам ни что не помешает посмотреть и попробовать эту отличную RDBMS.
+1
overPlumbum #
при использовании Slony SELECT-ы тоже отлично работают
0
kirushik #
Только slony работает (или всё же работают?, «слоны» ведь) на триггерах, заметно ударяя по производительности insertов. А тут всё через wal-логи, я так понял.
Круто, буду попробовать.
0
overPlumbum #
ну да, лаг в единицы секунд у слонов это как нечего делать.
будем ждать пока WAL-репликацию до ума доведут, там пока не всё гладко (оно в разработке, это понятно).
слоны очень приятны своей надёжностью и гибкостью посмотрим что тут будет.
0
overPlumbum #
кстати на саму производительность вставки slony влияет не очень сильно.
я правильно понял что ты говоришь о времени через которое эти данные появятся на реплике?
0
kirushik #
У меня получилось уменьшение скорости запроса (именно запроса, не репликации) где-то на 15%.
Это не так плохо, как какой-нибудь триггерный rubyrep (рост в 4 раза на тестовой десктопной машине, измерено с помощью `time pgbench -t 10000`), но всё же чувствительно. При этом rsync writeahead-логов, понятно, никакой сопоставимой дополнительной нагрузки не даёт (для случай warm standby я это также пробовал).
+2
Kodeks #
И в Oracle тоже. Дорогой тролль, новость не об этом.
–2
NickyX3 #
Я в общем то и не пытался кого то троллить, хоть и люблю это делать. Просто забавно бывает читать такие восторженные записи о постгри, его «новых» возможностях и т.п. когда такие «стремные и отстойные» по словам фанатов постгри, как MySQL умели это чуть ли не с рождения
0
alekciy #
Что-то есть в MySQL чего нет в PostgeSQL, что-то есть в PostgeSQL что появилось в MySQL не так давно. Часть вещей ни когда не будет иметь аналогов в другой СУБД. Правильно говорят, не о том речь.
0
Kodeks #
Люди радуются новым возможностям, потому что используют его.
0
davojan #
Warm standby появился в постгресе раньше 8.4, по крайней мере у нас он прекрасно работает на 8.3.

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

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

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

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.