Решения PostgreSQL против Oracle для высокой доступности?

8

PostgreSQL имеет матрицу различных вариантов высокой доступности, которые представляют множество различных способов встраивания репликации в СУБД.

Вот матрица возможностей высокой доступности, балансировки нагрузки и репликации PostgreSQL

Вопросов

Какой из подходов в матрице высокой доступности PostgreSQL поддерживается Oracle?
Оракул делает высокую доступность с методами, которые не доступны с PostgreSQL?

oracle postgresql

— военно-картографическая служба
источник

7

Репликация Oracle Data Guard аналогична «горячему / теплому резервированию с использованием PITR» в PostgreSQL, который встроен в базу данных начиная с PostgreSQL 9.0. Версия 9.1 также добавляет синхронную репликацию. Одно из преимуществ PostgreSQL перед Oracle заключается в том, что Sync Rep можно контролировать для каждой транзакции. Вы можете иметь полностью синхронный «Важно!» Транзакция, сопровождаемая асинхронной транзакцией «ОК, чтобы проиграть» в Postgres.

Oracle RAC похож на то, что PostgreSQL помечает как «отказоустойчивый диск» в этой сетке. Основное отличие состоит в том, что RAC полностью интегрирован в продукт Oracle, а «Отказ от общего диска» просто описывает метод выполнения каких-либо действий. Вы должны собрать необходимое программное обеспечение для работы с кластерами для PostgreSQL, и существует множество продвинутых вещей, которые RAC делает, вам будет сложно скопировать в PostgreSQL. Я регулярно слышу, что большинство из этих вещей настолько сложны в настройке, что лишь немногие из установок Oracle тоже их понимают - просто потому, что RAC встроен, не означает, что он настраивается автоматически.

Главное, что вы можете сделать в Oracle, который очень сложно дублировать в PostgreSQL, - это репликация с несколькими хозяевами. В PostgreSQL можно выполнять multi-master, но только с помощью дополнительного программного обеспечения, такого как Bucardo. И все такие программы по-прежнему имеют больше ограничений на то, что вы можете с ними делать, чем обеспечивают установки Multi-Master Oracle.

— Грег Смит
источник

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

— Ams

Стоит отметить, что multi-master - это иногда решение для поиска проблемы после успешного шага продаж Oracle.

— Роб Грант

4

Я не уверен, что понимаю часть «поддерживается Oracle» в вашем вопросе. Postgres никак не «поддерживается» Oracle.

Физический StandBy от Oracle эквивалентен потоковой репликации PostgreSQL.

При использовании потоковой репликации асинхронная репликация PostgreSQL эквивалентна резервированию Oracle с использованием режима «Максимальная производительность», тогда как синхронная (с 9.1) репликация PostgreSQL эквивалентна резервированию Oracle с использованием режима «Максимальная доступность».

У Oracle есть еще одна опция, называемая Real Application Cluster (RAC), которая недоступна в Postgres (она также выполняет балансировку нагрузки и автоматическое перенаправление сеанса на другой узел, если он отключается)

— a_horse_with_no_name
источник

Я полностью понимаю, что Postgres не поддерживается Oracle. Я пытаюсь выяснить, какие подходы к репликации реализованы обоими продуктами. Я думаю, что если подход к репликации достаточно хорош для Oracle, то это, вероятно, один из лучших подходов к репликации.

— Ams

2

Причина, по которой существует так много вариантов репликации, заключается в том, что каждый из них подходит для разных типов приложений. Идея, что некоторые "достаточно хороши", а другие нет, не соответствует действительности. Например, подход репликации на основе триггера не популярен для Oracle. Но это в PostgreSQL и MySQL, потому что он подходит для типов приложений, к которым Oracle не стремится.

— Грег Смит

1

В Oracle у вас есть выбор между активным горячим резервированием и использованием RAC .

Основной целью высокой доступности является устранение отдельных точек отказа. RAC делает это на уровне сервера, обеспечивая отказ сервера без прерывания работы службы. Вам нужно будет добиться чего-то похожего на стороне хранилища, используя ASM , зеркалирование и два или более физически независимых пула хранения (или SAN).

Использование горячего резервирования будет означать прерывание обслуживания в случае сбоя, но оно проще и имеет меньше «технических компромиссов»

Хорошее качество оборудования также важно, например, SAS, а не SATA, резервные блоки питания, источники бесперебойного питания и т. Д.

Есть и другие аспекты высокой доступности, которые вам, возможно, придется рассмотреть (например, человеческие ошибки) - в этом документе Oracle обсуждается их более подробно.

— Джек говорит, попробуйте topanswers.xyz
источник