Репликация базы данных для избыточности с использованием бесплатной базы данных и Java с веб-приложением Spring & Hibernate

Question

Я имею в виду это:

На каждый сервер: (они все настроены идентично )

• Свободная база данных, такая как MySQL или PostgreSQL .
• Tomcat 6.x для размещения Java-приложений на основе сервлетов
• Hibernate 3.x в качестве инструмента ORM
• Весна 2,5 для бизнес-уровня
• Калитка 1.3.2 для слоя презентации

Я размещаю балансировщик нагрузки перед серверами и запасной балансировщик нагрузки на случай, если мой основной балансировщик нагрузки выйдет из строя.

Я использую Terracotta , чтобы реплицировать информацию о сеансе между серверами. Если сервер выходит из строя, пользователь должен иметь возможность продолжить свою работу на другом сервере, в идеале, как будто ничего не произошло. Осталось «решить» (поскольку я на самом деле не проверял это и, например, не знал, что мне следует использовать в качестве балансировщика нагрузки), это репликация базы данных, которая необходима.

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

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

Answer 1

Поскольку вы уже используете Terracotta и считаете, что вторая БД - хорошая идея (согласен), вы можете рассмотреть вопрос о расширении роли Терракоты. У нас есть клиенты, которые используют терракоту для репликации базы данных. Вот краткий пример / описание, но я думаю, что они перестали поддерживать клиентов для этого продукта.

http://www.terracotta.org/web/display/orgsite/TCCS+Asynchronous+Data+Replication

Answer 2

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

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

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

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

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

Пожалуйста, прочитайте главу Высокая доступность, Балансировка нагрузки и Репликация в документации Postgres.

Answer 3

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

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

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

Answer 4

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

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

Answer 5

Вот идея. Прочитайте книгу Тео Шлосснагла Торговые интернет-архитектуры .

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

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

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