Synchronous replication в 9.1 — это возможность проводить транзакции в синхронном режиме (с подтверждением записи WAL от standby). Standby уже достаточно давно может переходить в активный режим с помощью trigger file в pg_standby (или pg_ctl promote в 9.1), но при этом primary придется убивать самому.
Самый частый use case для сторонней репликации — это упомянутая частичная репликация данных, скажем, на одной ноде нужна таблица A, на другом — таблица B.
Второй по частоте — это когда вы думаете, что вам нужен multi-master, который есть в Bucardo, но нет в WAL-based replication.
Третий — это уже упомянутая каскадная репликация.
Ну и пограничный случай — когда нужно зареплицировать данные из постгреса куда-нибудь еще, триггерную репликацию можно написать практически на коленке, а вот заставить другую СУБД понимать WAL от PostgreSQL — это тот еще fun :-).
Никто на самом деле не знает, как правильно произносить название СУБД, поэтому все говорят Postgres :-). Вот — доклад с последнего PGCon на волнующую всех тему :-)
Познавательная ведомость, спасибо. Есть мнение, что эти затраты могут окупиться концертной деятельностью, а альбом записывать нужно для того, чтобы стать более популярным, получать больше денег за концерты, а не для того, чтобы заработать на нем все деньги и больше не давать концертов. Я заплатил за каждый альбом в своей фонотеке, но жалобы звукозаписывающих компаний, одновременно с жалобами музыкантов на эти компании и преследованиями в суде домохозяек за музыку из p2p сетей заставляют задуматься, что деньги эти распределяются каким-то неправильным способом.
Вот только конфликты в такой системе будут происходить гораздо чаще, и они внесут больший вклад в общую производительность, чем откат транзакций при конфликте в MVCC.
Я имел ввиду без существенного замедления для случаев, когда конфликтов нет, т.е. в нормальных условиях для абсолютного большинства транзакций. В случае, когда конфликт есть, корректность важнее скорости, если же это не так — можно установить repeatable read и вернуться к поведению, которое было в 9.0 и более ранних версиях.
В PostgreSQL 9.1, beta которой вышла на днях, изменено поведение уровня Serializable. Новая фича называется SSI (Serializable Snapshot Isolation), и гарантирует True serializability без существенного замедления работы СУБД. Предыдущее поведение Serializable стало Repeatable Read. Подробнее: www.postgresql.org/docs/9.1/static/transaction-iso.html#XACT-SERIALIZABLE. PostgreSQL, кстати, первая СУБД, реализовавшая SSI.
Судя по max_fsm_pages у вас PostgreSQL 8.3 или более ранняя версия. Я бы для новых установок рекомендовал 9.0, текущая версия 9.0.4 достаточно стабильная для использования в production.
Советы, приведенные вами (со ссылкой на книгу) очень неоднозначны, для того, чтобы менять tuple_cost/page_cost в оптимизаторе нужно четко представлять себе, что они меняют, выбор этих параметров сильно зависит от соотношения доступная RAM/размер базы данных и скорость произвольного доступа к устройству хранения данных.
Интересно то, что план запроса зависит не только от объема данных, но и от их распределения, а предсказание последнего в такой щепетильной теме как выборы — скорее задача политологов. Хотя это QA Helmes не оправдывает никак — им следовало тестировать результат на нескольких полноразмерных выборках с различными распределениями голосов за основных кандидатов.
На 4ой прошивке стало резко хуже, но некоторые тормоза наблюдались и до нее, на 3.1 если я не ошибаюсь, давно это было. Регулярных подвисаний на 4.0 я не наблюдал, наблюдал 2-3 секундные паузы при приеме звонков, запуске почты и сафари, или плейера, т.е того, что на 2.0 и на 3.0 работало быстро. При этом самую для полезную функцию 4.0, меню настройки тезеринга, в 4.2 по-ошибке выключили именно для iPhone 3G.
Все это заставляет меня к новым версиям iOS относиться консервативно, т.к. покупать новый телефон каждый год я не хочу. Хотя для iPhone 4 вряд ли начнутся тормоза, более мощное железо в телефонах Apple появится предположительно летом вместе с iOS 5 (вот тут и буду ждать подвоха), а вот для iPad вполне может быть замедление уже сейчас. Посмотрю пока пару дней…
Интересно, как это обновление повлияло на общую производительность устройства? В Твиттере и на форумах Эпл встречаются сообщения о замедлении переключения между приложениями и подтормаживании некоторых визуальных эффектов на iPhone 4/iPad. Учитывая то, что Apple разрабатывает эту прошивку в расчете на iPad 2, у которого более быстрый процессор, я пока подожду обновляться, почитаю отзывы других. Не хочется повторения ситуации с iPhone 3G, когда из вполне быстрого и функционального устройства постепенно сделали ужасный тормоз.
Был бы очень интересен анализ точности предсказания погодных условий, те насколько верно тот или иной сервис предсказывает дождь, туман или снегопад. По-моему ошибка в прогнозе на 2-3 градуса не настолько неприятна, как неверное предсказанный дождь (когда отменяешь из-за него планы на выходные, а в итоге небо чистое) или снегопад.
Эх, если бы хотя бы за неделю знать, а так только - привет из солнечного Крыма :)
Надеюсь попасть на N-ую встречу для какого-нибудь не слишком большого N.
Самый частый use case для сторонней репликации — это упомянутая частичная репликация данных, скажем, на одной ноде нужна таблица A, на другом — таблица B.
Второй по частоте — это когда вы думаете, что вам нужен multi-master, который есть в Bucardo, но нет в WAL-based replication.
Третий — это уже упомянутая каскадная репликация.
Ну и пограничный случай — когда нужно зареплицировать данные из постгреса куда-нибудь еще, триггерную репликацию можно написать практически на коленке, а вот заставить другую СУБД понимать WAL от PostgreSQL — это тот еще fun :-).
Советы, приведенные вами (со ссылкой на книгу) очень неоднозначны, для того, чтобы менять tuple_cost/page_cost в оптимизаторе нужно четко представлять себе, что они меняют, выбор этих параметров сильно зависит от соотношения доступная RAM/размер базы данных и скорость произвольного доступа к устройству хранения данных.
Хороший обзор тюнинга сервера приведен в книжке Грэга Смита (Greg Smith):
www.packtpub.com/postgresql-90-high-performance/book
Статья Грэга в PostgreSQL Wiki:
wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server
Все это заставляет меня к новым версиям iOS относиться консервативно, т.к. покупать новый телефон каждый год я не хочу. Хотя для iPhone 4 вряд ли начнутся тормоза, более мощное железо в телефонах Apple появится предположительно летом вместе с iOS 5 (вот тут и буду ждать подвоха), а вот для iPad вполне может быть замедление уже сейчас. Посмотрю пока пару дней…
Надеюсь попасть на N-ую встречу для какого-нибудь не слишком большого N.