Реплікація деяких таблиць з однієї бази даних postgres в іншу


9

У мене склалася така ситуація: у мене є три машини, на яких працює бази даних postgresql. Одна машина містить інформацію про обліковий запис клієнта (зателефонуйте цій машині C), інші дві машини зберігають інформацію про реєстрацію клієнта (викликайте ці L1 та L2). Причина розбиття полягає в роздільному завантаженні на декілька машин (тому деякі клієнти надсилають інформацію про реєстрацію до L1, деякі до L2 ... а може бути, і деякий час L3, L4, ...).

Отримуючи інформацію про реєстрацію, в принципі, я хотів би мати можливість приєднатися між таблицями реєстрації в Ln і таблицями облікових записів клієнта на C. Насправді я не можу робити такі приєднання (навіть якщо я міг би, хотів би щоб уникнути завантаження C).

Моя думка полягає в тому, щоб тиражувати таблиці на C на кожен з L1, L2, ..., щоб я міг робити з'єднання. Що стосується таблиць з C, то C - головний, а L1, L2, ... - раби. Але для інших таблиць на L1, L2, ... ці машини є майстрами. Його реплікація не зовсім головна-майстерна, і чи не зовсім вона-підлеглий.

Чи можна переконати реплікацію postgres (у мене працює 9.1) чи ні, чи є інші пакети, які б виконали цю роботу. В крайньому випадку я можу записати якийсь код, періодично синхронізуючи таблиці (я можу терпіти деяку затримку), але було б непогано!

Заздалегідь спасибі.


1
Можливо, використовуйте FDW на автоматах для доступу до C? Хоча це спричинило б хіт на C. Матеріалізовані погляди можуть зменшити показник ефективності, але я не зовсім впевнений, як PostgreSQL виявляє оновлення для іноземної таблиці. Якщо це зробити автоматично (що, як видається, пропонує закінчення документації Materialized View), це може повністю вирішити вашу проблему. Це 9.3 особливості. Допомогти може також дуже активний список розсилки.
jpmc26

Відповіді:


4

На PostgreSQL 9.3 ви можете postgres_fdwпрозоро запитувати сторонню таблицю на іншій машині.

У старих версіях dblinkможе бути варіант, про який згадував Ендрю.

Інший варіант - використовувати інструмент на зразок Londiste або Slony-I для копіювання потрібних таблиць. Я рекомендую використовувати для цього Londiste, це буде набагато простіше. Він створює на столі тригери для виявлення вставки / оновлення / видалення та реплікує їх за допомогою власного клієнта / сервера та системи черги до іншої бази даних, де він робить відповідну вставку / оновлення / видалення. Я використовую його у виробництві на декількох сайтах клієнтів, і він працює дуже добре.

Майбутнім варіантом (сподіваємось у PostgreSQL 9.5) буде протокол логічної потокової логічної реплікації, вилучення набору логічних змін та двонаправлена ​​реплікація, що дозволить реплікувати окремі бази даних або таблиці на рівні SQL. Частина роботи для цього була покладена на PostgreSQL 9.4, але недостатньо, щоб зробити його корисним для того, що ви хочете зробити.


3

Для цього слід використовувати dblinks та матеріалізовані представлення. Обидві функції вбудовані в останні версії Postgres:

http://www.postgresql.org/docs/9.3/static/rules-materializedviews.html

http://www.postgresql.org/docs/9.3/static/dblink.html

По суті, ви будуєте Mview на кожній базі даних L1, L2 ... з даними, витягнутими з таблиць на C, а потім використовуйте оновлення Mview, щоб періодично оновлювати Mviews так часто, як потрібно. Дані зберігаються локально, тому доступ до них дуже швидкий. Це підходить лише в тому випадку, якщо дані відносно статичні і ви не заперечуєте проти того, щоб локальні бази даних періодично мали застарілу інформацію. Ви повинні встановити частоти оновлення, щоб правильно цим керувати, а якщо це не прийнятно, слід просто скористатись посиланням на базу даних і мати справу з невиправданою повільністю.

Якщо вам потрібна додаткова функціональність, проект знімків надає розширені функції, такі як швидке оновлення та журнали знімків:

http://pgfoundry.org/projects/snapshot/

Завдяки цьому ви можете зробити оновлення лише оновлення рядків, які потребують оновлення, що може зробити їх надзвичайно швидкими для великих, нееластичних наборів даних, мінімізуючи збої у вашій програмі. За замовчуванням Mviews повністю скидаються та відтворюються в Postgres, що може бути дуже поганим для продуктивності з зрозумілих причин.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.