Поддержка отработки отказа для БД

Question

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

Наше требование состоит в том, чтобы просто иметь два сервера базы данных, один из которых предназначен только для синхронного резервного копирования, но если основной сервер не работает, то вторичный сервер должен автоматически начать действовать в качестве основного сервера.

Кто-нибудь оценивал MySQL, PostgreSQL или любой другой сервер БД для такого случая использования?

Edit: Мы думали об использовании кластера MySQL, но теперь кажется, что он находится под лицензией GPL, с которой мы не сможем работать. Может ли кто-нибудь предложить решение для синхронной репликации / кластеризации, которое можно использовать? В настоящее время мы используем HSQL, поэтому решение с использованием HSQL в кластерном режиме будет идеальным для нас, но мы открыты для изменений.

Answer 1

Ресурсы Stackoverflow
MySQL поддерживает репликацию из коробки: см. Этот вопрос для MySQL: Решения по масштабированию для MySQL (репликация, кластеризация)

PostgreSQL также поддерживает репликацию, см. Этот вопрос: Стратегии репликации PostgreSQL

Если ваши требования просты, MySQL будет работать
Я использовал MySQL - простой сценарий аварийного переключения мастер-мастер, использующий настройки, которые я прочитал в High Performance MySQL . Я очень рекомендую эту книгу, если вы заинтересованы в использовании MySQL.

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

Answer 2

Просто для полноты, база данных H2 имеет некоторую поддержку кластеризации , но по сравнению с функциями MySQL и PostgreSQL она очень ограничена, это действительно только аварийное переключение.Сначала я посмотрю на HA-JDBC .

Answer 3

Не уверен, что это находится в желаемом ценовом диапазоне большинства людей типа FOSS :-), но мы используем DB2 9.7 именно для этой цели (на самом деле, мы в основном используем DB2 / z на мейнфрейме для него, но некоторым клиентам нравитсяОпция DB2 / LUW (Linux / UNIX / Windows) для небольших систем).

В DB2 встроены функции высокой доступности (HA), и вы можете использовать db2haicu, утилиту конфигурирования экземпляра DB2 High Availability (необходимолюблю те генераторы аббревиатур, которые использует Big Blue) для сравнительно безболезненной настройки.

Он активен / пассивен, как вам нужно, хотя DB2, безусловно, способна к активным / активным настройкам для балансировки нагрузки.Конкретные установки, с которыми мы наиболее знакомы на низком уровне (все, кроме мэйнфреймов), на самом деле являются общими дисковыми, причем HA применяется только к ресурсам СУБД, но не к данным, но вы также можете разделить данные с помощью функций репликации DB2.

У нас был один клиент (по крайней мере), использующий Q-репликацию, что очень малоМетод репликации интенсивности, близкий к синхронному, но не совсем.На самом деле DB2 также обеспечивает реальную синхронную репликацию.

На сайте DeveloperWorks есть интересная статья о том, как все это сочетается, а также различные варианты.

Answer 4

Существует сторонний продукт, работающий с HSQLDB:

http://ha -jdbc.sourceforge.net /

Answer 5

для простого переключения при сбое, когда серверы находятся в одном месте.Вы можете использовать DRBD и Heartbeat .

В двух словах: DRBD сохраняет данные на 2 серверах одновременно.полностью прозрачен для системы.с помощью heartbeat резервные проверки по отношению к главному серверу, если он недоступен, он захватывает ресурс, монтирует его и запускает демон базы данных.(работает с mysql, postgres и, скорее всего, с большинством других демонов)