Вопрос по внутренностям Postgres.
Здравствуйте. Сейчас занимаюсь синхронизацией баз постгрес на разных машинах и дошло до того, что, видимо, придется разбираться с особенностями работы на низком уровне.
Версия СУБД - 7.4.1, без возможности обновления в обозримом будущем. ОС - кастомная сборка Linux.
Что сделано.
Существующие решения: Slony, pg-pool-II по разных причинам не устроили. Выбор был сделан в пользу сихронизации файлов базы. На машине работает, как минимум, 2 базы (А и Б). Одну (А) надо полностью сихронизировать, другую (Б) - оставлять нетронутой. Произвожу синхронизацию (копирование) содержимого data/base/oid_of_base(А), data/global, data/xlog, data/clog. Обнаруженную проблему с переименованием второй базы (Б) и его oid'а данными другой синхронизируемой машины в pg_database решаю хак-переименованием в hex-режиме внутри файла data/global/1262. Скорее всего, это - неполное решение. Для переименования мне требовалось брать имя и oid базы (Б) при остановленном postmaster, для чего выявил отличие текущих имен баз от прошлых внутри файла 1262 в hex.
Сейчас обнаружилась серьезная проблема: в связи с тем, что журнал транзакций xlog и метаданные транзакций clog общие для всех баз, то при синхронизации одной базы, теряются "не слитые" в файлы базы изменения другой базы. Интернет подсказыввает, что в hex-виде работать с xlog не стоит, в связи со сложностью формата. Была попытка сделать что-то вроде force flush коммандами "CHECKPOINT;" и "START TRANSACTION; COMMIT;", но к успеху не привела. Сейчас подошел к тому, что придется разбираться с исходниками самого Постгрес в поисках рабочего механизма и делать на его основе ForceFlusher, работающего помимо воли Постгрес. Смотрю в сторону src/backend/access/transam/clog.c. Могли бы вы подсказать в каких файлах/функциях подсмотреть механизм, какие существуют подводные камни, либо выбрать более верное напрвление? Ну или человека, который разбирается. На ум пришел только Олег Бартунов, но не уверен, что он со своей высоты ответит.
Спасибо за внимание.
Не буду говорить за Олега, но
Не буду говорить за Олега, но я отвечу так: не нужно придумывать себе проблем, которые потом придётся решать.
Попытайтесь всё-таки решить проблему синхронизации ваших баз более правильным способом.
Легче устранить причины, по которым вас не устраивают стандартные решения репликации, чем делать то, что вы описываете.
>> Попытайтесь всё-таки
>> Попытайтесь всё-таки решить проблему синхронизации ваших баз более правильным способом
Я, собственно, и пришел на форум, дабы узнать как этот "правильный способ" выглядит.
Повторяю: версия СУБД - 7.4.1 и стандартные решения репликации в ней отсутствуют.
Slony предлагает вешать триггеры на готовые таблицы. В моем случае число таблиц постоянно растет и поддерживать решение на slony становится затруднительно. К тому же мне требуется быстрая смена роли со slave на master. По наследству достались таблицы без oid'ов и без pk. Все их отслеживать и переправлять оказалось довольно болезненно и неподдерживаемо. 3 тысячи повешенных триггеров серьезно просаживают производительность решения.
pg_pool лишен этих недостатков, но есть другие. Из серьезного - не поддерживается синхронизация после возвращения slave'а из оффлайна, да и просто нигде не аккумулирует изменения, пока slave был оффлайн. И опять-таки придется лезть в сишный код, но уже pgpool'а.
Другие готовые решения под мою версию отсутствуют.
Понимаете, вы мне сейчас
Понимаете, вы мне сейчас говорите: "у меня Жигули 1-й модели, но я хочу чтобы они ездили как Гранта". Для того, чтобы ездить как Гранта, нужна Гранта, а не Жигули 1-й модели. Да, вы можете взять в руки инструмент и попытаться довести до ума Жигули 1-й модели. В общем-то это ваше право, но не стоит думать, что вас сейчас завалят готовыми решениями о том как это делать.
7.4.x - очень древняя ветка, так что либо вам всё-таки придётся решать проблему обновлением БД, либо придётся отказаться от репликации в нормальном её виде.
А ненормальных решений много, например делать каждые 5-10 минут дамп БД и вливать его на резервный севрер (может не целиком, а только изменяемых таблиц). Можно сделать прослойку между клиентом и сервером, которая будет выполнять операции изменяющие данные на обоих серверах сразу, а не на одном.
Решение с дампом было
Решение с дампом было опробовано в самую первую очередь и не устроило по скорости. Таблицы могут меняться самые разные из примерно 6 сотен и их отслеживать - дело неблагодарное. Сервер-клиент иногда меняются местами и прослойка исключена. Если только выдирать из pg_pool перехват запросов на сокете. И еще вопрос, с какими исходниками будет проще разобраться.