Репликация баз данных для дублирования с помощью свободной базы данных и Java с Spring и В спящем режиме веб-приложение

Вы пытаетесь создать мультиосновную репликацию, которая является очень плохой идеей, поскольку любое изменение в любой базе данных должно копировать в любую базу данных. Это ужасно медленно - на одном сервере, можно получить несколько сотен транзакций в секунду с помощью нескольких быстрых дисков и RAID1 или RAID10. Это может быть намного больше, если у Вас есть хороший RAID-контроллер с кэшем с аварийным батарейным питанием. Если Вы добавите издержки общения со всеми Вашими серверами, то Вы получите самое большее десятки транзакций в секунду.

Если Вы хотите высокую доступность, необходимо пойти для теплого резервного решения, где у Вас есть сервер, который копируется, но не используется - когда основной сервер перестает работать, замена вступает во владение. Можно потерять некоторые недавние транзакции, если основной сервер перестает работать.

Можно также пойти для одного ведущего устройства, нескольких ведомой асинхронной репликации. Каждое изменение в базе данных должно будет быть выполнено на одном главном сервере. Но у Вас может быть несколько ведомых устройств, серверы только для чтения. Данные по этот ведомые серверы могут быть несколькими транзакциями позади ведущего устройства, таким образом, можно также потерять некоторые недавние транзакции в случае смерти сервера.

PostgreSQL действительно имеет оба типа репликации - теплое резервное устройство с помощью передачи журналов и одного ведущего устройства, несколько ведомых устройств с помощью slony.

Только если у Вас будет очень небольшое количество записей, можно пойти для синхронной репликации. Это может также быть установлено для PostgreSQL с помощью PgPool-II или Секвойи.

Считайте Высокую доступность, Выравнивание нагрузки и главу Репликации в документации Пост-ГРЭС для больше.

Для моего (управляемого Perl) веб-сайта я использую MySQL на двух серверах с репликацией баз данных. Каждый сервер MySQL является ведомым устройством и ведущим устройством одновременно. Я сделал это для redudancy, не для производительности, но установка хорошо работала в течение прошлых 3 лет, у нас не было почти времени простоя вообще в течение этого периода.

Относительно вопроса Кента / комментарий: Я использую стандартную репликацию, которая идет с MySQL.

Относительно механизма обработки отказа: Я использую функциональность обработки отказа DNSMadeEasy.com. Мне выполняли сценарий Perl каждые 5 минут через крон, который проверяет, работает ли репликация все еще (и также много других вещей, таких как загрузка сервера, исправность жесткого диска, Использование оперативной памяти, и т.д.). Во время нормального функционирования, быстрее этих двух серверов поставляет все веб-страницы. Если сценарий обнаруживает, что что-то неправильно с сервером (или если сервер просто снижается), DNSMadeEasy переключает записи DNS так, чтобы вторичный сервер стал основным. После того как "реальный" основной сервер вернулся, MySQL автоматически нагоняет в недостающих изменениях базы данных, и DNSMadeEasy автоматически переключается назад.

Вот идея. Книга Read Theo Schlossnagle Продаваемая интернет-Архитектура.

То, что Вы предлагаете, не является лучшей идеей.

Подсистемы балансировки нагрузки являются дорогими и не столь ценными, как они появились бы. Используйте что-то более простое для распределения загрузки между Вашими серверами (что-то как Wackamole).

Вместо того, чтобы дурачиться с репликацией DB, потратьте свои деньги на надежный сервер БД, отдельный от Ваших веб-серверов фронтенда. Сделайте регулярные резервные копии и в очень маловероятном событии отказа DB, возвратите выполнение как можно быстрее от обычных резервных копий.

AFAIK, MySQL действительно лучше нанимает быть масштабируемым. См. документацию http://dev.mysql.com/doc/mysql-ha-scalability/en/ha-overview.html

И существует блог, где можно смотреть на реальные примеры: http://highscalability.com/tags/mysql