Приветствую. Сегодня я хотел бы поговорить о такой неприятной ситуации, как отказ мастера в случае применения нативной репликации в PostgreSQL 9.x. Итак, предположим, что у вас есть кластер из двух и более PostgreSQL-серверов и на мастер внезапно упал метеорит. Логично предположить, что вам придётся сделать мастером одну из реплик. Сделать это можно двумя способами.

В предыдущей статье был рассмотрен пример с пространственными объектами и разделением доступа к ним по пользователям.
Теперь рассмотрим пример аудита данной базы. Нас интересует: кто, когда и что сделал с таблицей. Какую запись (читай «объект») добавил, какую удалил, какую изменил, чтобы в дальнейшем не было различных «недоразумений».

По приходу в одну контору, которая занимается разработкой карт, схем и планов, меня очень удивила одна вещь: не было централизованного хранилища всех материалов. Пользователи работали каждый со своими наработками. И если возникала потребность что-то взять из другого проекта – приходилось или бежать с «флэшечкой», или копировать файлы по сети. Что создавало неимоверное количество «мусора» в виде дубликатов разной свежести на множестве рабочих станций.

После наблюдения всего этого хаоса, я решил все это дело «причесать» и сделать централизованным хранение картографического материала, с разграничением прав доступа к отдельным проектам, да еще и с мониторингом изменений, внесенных в проекты.

По следам статьи Уникальный ключ в условиях распределенной БД.

У нас есть база которую мы хотим разделить. В идеальном случае хочется сделать master-master. Один из самых сложных моментов, это обеспечение уникальности ключей на всех серверах. И хорошо если база изначально проектировалась с учетом масштабирования… Опять же, это что-то из области идеала, который встречается, скажем так — не часто.

Итак у нас есть база которую нужно подготовить к синхронизации master-master — сделаем все ключи в нашей базе уникальными в пределах проекта.

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

Идея этого проектика (именно «проектика») возникла спонтанно. В компании используется memory-DB TimesTen, содержит одну большую таблицу с данными, более 150 млн записей, и объем около 15 гигов. TimesTen всегда работал исправно, ответ по любому запросу получали за считанные миллисекунды, всех это устраивало. В один из дней, T10 стал отвечать на запросы очень долго, время ответа увеличилось до 3-5 секунд. Техподдрежка конечно начала проведение работ по поиску проблемы, но параллельно мы задались вопросом, а для чего вообще используется T10, почему нельзя перенести базу на обычную СУРБД Oracle или Postgres?

Возникла задача внедрения streaming репликации Postgresql 9.1 на продакшене. А т.к. раньше с нею дела не имели, решили провести ее «эстремальное тестирование».

Для этого были запущены две виртуальные машины VMWare Player с Ubuntu Server. Установлена и настроена streaming репликация на Postgresql 9.1.

Приветствую. Хочу поделиться одним самописным костылём, авось кому-нибудь будет полезен.

Коротко о главном

Моделируем ситуацию: есть кластер PostgreSQL-серверов — мастер и n-реплик. Наступает черный день и одна(или несколько) реплик падает. Причины неважны — сдохла железка, уборщица перебила шваброй провод или НЛО временно зохавало серверную. Итог один — если реплика долго лежала, то сама она уже никогда не нагонится.

С 9.0 версии PostgreSQL есть встроенный механизм Master-Slave репликации (streaming replication).
Однако, с его появлением выбрасывать старые триггерные механизмы не следует.

В общем случае, если нам требуется нечто большее, чем одна абсолютно точная копия всего DB-сервера, то триггеры остаются с нами.

Примеры таких ситуаций:

• Если требуется failover (т.е. останавливается Master и все запросы временно идут на Slave, а потом запущенный Master начинает догоняется до актуального состояния со Slave).
• Master и Slave не являются 1:1 идентичными. Например, по какой-то причине на Slave надо держать дополнительные данные (базы/таблицы) или же копированию с Master подлежат не все базы/таблицы, или же при удалении данных — они должны сохраниться на Slave.
• В проекте приходится использовать продуктовый «зоопарк» — т.е. Master и Slave имеют по какой-то причине разные версии, или же версии одинаковые, но ОС разной «битности».
• В проекте требуется рекурсивная репликация Master-Slave1-Slave2-Slave3 или в реально нагруженном INSERT/UPDATE проекте к Master параллельно подключается больше, чем 1 Slave (хотя некоторые проекты имеют нагрузку, с которой могут нормально работать и до 5-6 Slave).
• Если по какой-то причине требуются различные права доступа к объектам базы на Master и Slave.

Добавляйте в комментариях дополнительные варианты.

Примечание: Возможность построения failover задекларирована месяц назад в версии 9.1 под названием «Synchronous Replication». Однако, лично я пока ещё эксперименты не проводил.

Вступление

Встречалась ли вам ситуация, когда необходимо реализовать хранение древовидной структуры в реляционной БД?



Примеров можно привести множество. Это и древовидные комментарии, и каталог продукции, и населенные пункты, разделенные по странам и областям. Я думаю, что каждый сможет самостоятельно привести несколько примеров.

В данном топике мы с вами поговорим об одной из тех возможностей, которые существуют для организации хранения деревьев в PostgreSQL — ltree.