|
Задавайте вопросы, мы ответим
Вы не зашли.
Преамбула:
В общем, есть "вычислительный кластер", расположеный на кучке серверов, и исторически использующий один единственный сервер базы данных, без всяких репликаций. [s]Ещё и древний как г**но мамонта[/s]
В связи с повышением нагрузки, и переходом на какбе "иные" модели взаимодействия с клиентами - встал вопрос о том, что один сервер БД никуда не годится.
В общем - что должна представлять из себя новая система:
- Представлять из себя распределённую сетевую базу данных, с высокой доступностью из любой точки кластера. Т.е. имеющая более одной точки подключения, чтобы кхм... "сервисы" кластера - могли использовать ближайшую и наиболее доступную точку.
- Иметь высокую отказоустойчивость.
- Поддержка транзакций.
- Мгновенная доступность изменений из любой точки подключения в пределах кластера.
- Разумный минимум трудозатрат на обслуживание.
Что есть:
- Есть - ВСЁ, и фактор железа неактуален, при необходимости закупят что нужно, в том числе и на оптическую транковую локалку не пожалеют при случае.
Собственно, вопросы:
- Насколько подходит MySQL NDB-кластер для этих целей?
- Какие существуют альтернативные решения, на основе простой репликации и пр.
- Какие ещё существуют коммерческие и некоммерческие решения, подходящие для этих целей?
Отредактированно Бананище (05.11.2012 01:09:58)
Неактивен
Попробуйте Percona XtraDB Cluster.
http://www.percona.com/software/percona-xtradb-cluster
Неактивен
Бананище написал:
1. Представлять из себя распределённую сетевую базу данных, с высокой доступностью из любой точки кластера. Т.е. имеющая более одной точки подключения, чтобы кхм... "сервисы" кластера - могли использовать ближайшую и наиболее доступную точку.
2. Иметь высокую отказоустойчивость.
3. Поддержка транзакций.
4. Мгновенная доступность изменений из любой точки подключения в пределах кластера.
5. Разумный минимум трудозатрат на обслуживание.
Отвечу по пунктам про MySQL NDB кластер.
1. да, система распределенная, но не в полной мере. Понятия "ближайшая" в нем нет - все ноды должны быть одинаково близко друг к другу. В NDB недопустимо разнесение кластера географически или по датацентрам (для такого потребуется репликация с кластера на кластер, в которой не будет синхронности). Вы можете обратиться к одной ноде с SQL-запросом, но получение данных из таблиц будут автоматически выполнять все ноды по кускам, а если JOIN, то это будет сопровождаться передачей всех данных с ноды на ноду.
2. да, это предусмотрено. Не любая конфигурация, но можно добиться высокого уровня отказоустойчивости, см. статью http://webew.ru/articles/252.webew
3. да
4. да
5. в пределах разумного. Придется писать скрипты, которые рестартят ноды, если они выпадают из кластера.
Тем не менее, это решение может вам не подойти по причине производительности. Из-за описанного алгоритма выполнения запросов, все запросы с JOIN будут работать медленно. Если у вас система типа форума со сложными запросами, то скорость работы упадет в десятки раз. Кластер оптимален для систем типа биллинга с выборкой всегда из одной таблицы и по первичному ключу (тут конкурируют hash-хранилища, но кластер дает отказоустойчивость и транзакционность).
Percona XtraDB Cluster по своему построению не содержит подобного регресса производительности, но я с ним еще не работал. Если получится использовать Percona XtraDB Cluster, напишите о своем опыте.
Неактивен
