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

Question

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

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

• Бесплатная база данных, например MySQL или PostgreSQL.
• Tomcat 6.x для хостинга сервлет на основе Java-приложения
• Hibernate 3.x как ОРМ инструмент
• Spring 2.5 для бизнес-слоя
• Wicket 1.3.2 для представления слоя

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

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

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

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

Answer 1

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

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

Answer 2

Вот идея. Прочитайте книгу Тео Шлосснагле Salable Internet Architectures.

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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

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

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

Подробнее читайте в главе High Availability, Load Balancing, and Replication в документации Postgres.

Answer 5

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

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