Реплікація PostgreSQL

Ми постійно ламаємо це навколо офісу, і питання продовжує виникати. Як ви маєте справу з реплікацією PostgreSQL? Я навіть не обов'язково говорю про розширені кластери, просто простою програмою Master-Slave, Master-MultiSlave та Master-Master. Я вважаю, що налаштувати його для MySQL, як правило, досить просто. Перехід на відмову - це просто, якщо не ідеально, особливо для того, наскільки це легко налаштувати. Ми грали зі Слоні, але це трохи занадто добре (зміни схем вимагають втручання, нові бази даних вимагають втручання тощо). PGPool2 виявився досить приємним, доки вузол не впав, і ми не змогли знайти витончений спосіб (окрім зведення всього та повторного повторного впадіння вузла), щоб повернути реплікацію в синхронізацію. В основному ось що я зазвичай шукаю:

• Просте налаштування (я вирішуватиму складні налаштування, але легко розширити)
• Спрощена відмова
• Повернення впалого вузла просто вимагає часу (наприклад, як mysql. Сервер виходить з ладу, ви підносите його і чекаєте, коли реплікація наздожене)
• Зміни схеми не порушують реплікацію
• Додавання нової бази даних до сервера є безпроблемним (тобто, як mysql, ви можете реплікувати цілий сервер БД, тому на базі даних створюється нова база даних, вона автоматично поширюється на підлеглий)

MySQL обробляє більшість із них досить добре, але я певну прихильність до PostgreSQL. Крім того, у нас є деякі ситуації, коли це наш єдиний варіант, і ми хотіли б додати реплікацію до суміші. Що ви зараз використовуєте та як ви ставитесь до свого рішення? Я обіцяю, що це не MySQL проти PostgreSQL, тому що я не намагаюся почати. :)

Коротка відповідь - для PostgreSQL ще немає такого рішення, якщо вам потрібні онлайн-раби для читання.

Зараз у цій галузі тривають два основні проекти розвитку, які включені до PostgreSQL 9.0 (весна / літо 2010), а саме:

• Синхронна реплікація:

http://wiki.postgresql.org/wiki/NTT's_Development_Projects

• Читайте тільки рабів із гарячою готовністю:

http://wiki.postgresql.org/wiki/Hot_Standby

які в поєднанні мають на меті досягти простоти використання реплікації стилю MySQL за вирахуванням помилок / проблем, які має MySQL, а також надійність, яку користувачі знають з PostgreSQL.

Все це було розпочато маніфестом із команди Coregre PostgreSQL у 2008 році:

http://archives.postgresql.org/pgsql-hackers/2008-05/msg00913.php

Рішення для реплікації PostgreSQL на сьогоднішній день з найбільшою базою користувачів - це Slony-I (дорожче для запису, робить схему змінами нескінченно), WAL доставка / walmgr (Slave не можна використовувати в Інтернеті) і pgQ / londiste від Skype / Skytools ( більше інструментів / будівельних блоків, ніж готового рішення).

Я написав кілька речей про журнал доставки, walmgr та Slony-I, див

http://blogs.amd.co.at/mt/mt-search.cgi?blog_id=1&tag=pgrep&limit=20 для отримання додаткової інформації.

І кинути ще одне рішення в кільце: rubyrep.

Для порівняння з вашими вимогами:

• Просте налаштування
  Так, це насправді головна увага рубірепу.
• Спрощена відмова
  Так. Насправді рубіреп виконує реплікацію master-master - щоб провалитись, взагалі ніяких дій не потрібно. Просто почніть використовувати іншу базу даних.
• Зміни схеми не порушують реплікацію
  Так.
  Для змін не первинного ключа реплікацію навіть не потрібно зупиняти (але переконайтеся, що схема змінюється з обох сторін одночасно).
  Для додавання / видалення таблиць просто перезапустіть демон реплікації. Лише зміна стовпця первинного ключа таблиці вимагає трохи зусиль.
• Додавання нової бази даних до сервера є безпроблемним (тобто, як mysql, ви можете копіювати цілий сервер БД, тому на
  майстрі створюється нова база даних, вона автоматично поширюється на підлеглий). Це підтримується лише обмежено: кожен rubyrep інсталяція копіює лише одну базу даних одночасно. (Але дуже просто налаштувати реплікацію для декількох баз даних.)

Ви не згадували про необхідність використання гарячого підлеглого читання, тому я збираюся запропонувати використовувати Heartbeat із загальним сховищем або DRBD. Це просто робить правильно, а адміністрація - вітер. Це еквівалент Linux старішої кластеризації Microsoft SQL Server. Один вузол активний, а інший - пасивний, тоді як дані поділяються між ними. Вам не доведеться турбуватися про реплікацію на основі SQL, оскільки це все обробляється нижче на рівні блоку.

Серйозно, це, безумовно, найкраще рішення, якщо вам не потрібні раби з читанням. Архів WAL був у кращому випадку гаком, і ви повинні налаштувати все заново, якщо ви коли-небудь порушите процес доставки для перезавантаження сервера. неохайний і лондист не ріжуть гірчицю. Якщо ви хочете залишитися на головному дереві та не розповсюджувати рекламу, Heartbeat - це найкраща пропозиція.

З ваших вимог виходить, що PITR - це найпростіший спосіб вирішити вашу проблему:

Он-лайн резервне копіювання та відновлення часу (PITR)

Ви не сказали, що вам потрібно запитувати підлеглий сервер, тож PITR може бути правильним.

Це стандартна частина PostgreSQL від версії 8.0, тому ви, мабуть, вже маєте все необхідне для його роботи та роботи.

Якщо ви знайдете інструкції занадто багатослівними, подивіться на SkyTools WalMgr, який зробить процес створення / переходу в єдину командну задачу даних в режимі гарячого очікування.

Для складніших сценаріїв реплікації я мав хороший досвід Slony-1, але PostgreSQL має багато хороших варіантів реплікації / HA.

Якщо ви хочете асинхронну реплікацію головного / підлеглого, розгляньте Londiste (частина пакету skytools з Skype) wiki.postgresql.org/wiki/Londiste_Tutorial

Встановити це просто, додавання нової БД легко, реплікація просто "наздоганяє".

Відмовка не вбудована. Вам потрібно буде змінити рядки підключення до додатків або замаскувати з'єднання БД за іншим рівнем програмного забезпечення.

Деякі зміни схеми прості. Іншим важче. Це залежить від вашої заявки. Наступна версія skytools (версія 3.0) повинна обробляти DDL і включати засоби, щоб полегшити відмову.

Ми переїхали до Лондісте після того, як виявили Слоні занадто болісною для використання.

Дивіться тут дискусію, можливо, це може допомогти:

http://blog.endpoint.com/2009/05/competitors-to-bucardo-version-1.html

і

Конкуренти першої версії Bucardo, знайдені нижче на сторінці:

http://www.planetpostgresql.org/

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

Тепер, є можливість сортувати рулону власний реплікації з Postgres , використовуючи протокол записи головки (WAL) Доставка:

http://www.postgresql.org/docs/8.3/interactive/warm-standby.html

Це, в основному, ви можете перевести вторинний вузол у режим безперервного відновлення та імпортувати в нього журнали транзакцій кожні {невеликий інтервал}. Конфігурація Postgres має "заглушки", які дозволяють вам робити певні дії, коли Postgres, коли WAL завершено, і так ні, і саме це налаштоване на налаштування - використання цих "заглушок".

Однак це не дозволяє вам робити головний та / або кругову реплікацію.

У будь-якому випадку це, безумовно, працює для виправдання, але я б не називав це "легким налаштуванням", "спрощеним відмовою", "безшовним" або чим-небудь подібним.

За винятком "додавання нової бази даних" ви можете спробувати Mammoth Replicator ( https://projects.commandprompt.com/public/replicator ). Це відкритий код, простий у налаштуванні та підтримує відмову. Основними обмеженнями є одна база даних та неможливість повторити зміни DDL, обидва входять до списку TODO.

Postgres-R виглядав багатообіцяючим, але я не знаю, чи проект ще живий.

Я зараз дивлюсь на реплікатор Вольфрама, я ще далеко від певного висновку, але, напевно, варто подивитися.

www.continuent.com