Архитектура MySQL Cluster

Архитектура MySQL Cluster
Григорий Рубцов
MySQL AB / Sun Microsystems
План доклада
• Архитектура
• Отказоустойчивость
• Производительность
– плюсы
– минусы
• Практика
Приобретение MySQL компанией Sun
•
•
•
Сделка завершилась в 2008 году
Sun и MySQL совместными усилиями сделают продукты и услуги
ближе к заказчику.
– Корпоративная поддержка 24x7x365 географически ближе
– Больше поддерживаемых платформ
– Профессиональные услуги и обучение в России
Обе компании твердо стоят на позициях Open Source
Миссия Sun/MySQL:
Сделать доступную каждому высококлассную СУБД.
Архитектура сервера MySQL
Общая архитектура кластера
Особенности архитектуры:
• Избыточность
– Данных NoOfReplicas (min: 2)
– SQL-нод
– mgm-нод (управляющих нод)
• Разбиение данных
– число долей равно числу дата-нод
– критерий разбиения – первичный хэш-индекс таблицы
• “Shared nothing”, общая только сеть
• Транзакционность ( READ_COMMITTED )
Лицензия
• Две формы издания
– Community, 100% GPL
– Enterprise, коммерческий продукт с поддержкой
(MySQL Cluster Carrier Grade Edition)
• Исходный код общий
• MySQL Cluster 6.2 можно скачать, 6.2 - это версия
ndb (не связана с MySQL 6)
Открытый NDB API
• Позволяет обойти SQL-сервер или
самому им быть
• http://dev.mysql.com/doc/ndbapi/en/
NDB API (пример)
NdbOperation *myOperation
= myTransaction->getNdbOperation(myTable);
if (myOperation == NULL)
APIERROR(myTransaction->getNdbError());
myOperation->insertTuple();
myOperation->equal("ATTR1", i);
myOperation->setValue("ATTR2", i);
if (myTransaction->execute( NdbTransaction::Commit ) == -1)
APIERROR(myTransaction->getNdbError());
Хранение данных
• Фрагментация по первичному хэш-индексу
• Хранение в памяти и на диске (с версии 5.1)
• B-tree индексы – отдельные таблицы – также
фрагментируются
• До 48 дата-нод
• Сеть должна быть быстрой (гигабит)
• Все соединения между нодами без авторизации
и без шифрования
6 нод, NoOfReplicas=2
Отказоустойчивость
• Возможность резервирования всего
– отсутствие единой точки отказа
• Не забудьте про резервирование сети
– два свича, по 2 сетевых карты
• Географическая распределенность:
– репликация кластеров
• Автоматическое восстановление дата-ноды
Арбитраж
• Фрагментация кластера может привести к двум
потенциально работоспособным частям.
• «Split brain» - это плохо!
• Для этого есть арбитр (mgm или sql-нода)
– выборы арбитра только после того, как все алгоритмы
арбитража отработали
– ArbitratorRank=0 (never), 1 (high), 2 (low)
– при равном ArbitrationRank, min(nodeid)
Алгоритм арбитража
1.
2.
3.
Вижу ли я по крайней мере одну дата-ноду из каждой группы?
–
–
–
–
–
–
нет – выключиться
да – продолжить алгоритм
Есть ли среди отключившихся дата-нод по одной ноде из каждой
группы?
нет – продолжить работу (вторая часть выключится по правилу 1)
да – продолжить алгоритм.
Спросить арбитра.
арбитр недоступен – выключиться.
арбитр доступен, узнать присутствую ли я в текущей конфигурации?
•
нет – выключиться
•
да – продолжить работу
Производительность
• Дата-нода осуществляет выборку данных и поиск по
btree-индексу в своем фрагменте
• Условие WHERE может выполняться на дата-ноде
• SET engine_condition_pushdown=1;
– только сравнения с константами
• age>27 OK
• (age – 27) > 0 плохо
• Используйте EXPLAIN EXTENDED + SHOW WARNINGS
Производительность
• Выполняются на SQL-ноде:
–
–
–
–
WHERE, когда не работает pushdown
ORDER BY
JOIN
Подзапросы
• Простые запросы – быстро и эффективно
• Не все составные запросы одинаково полезны
• Нельзя вслепую заменить MyISAM на NDB
Практика применения
• Alcatel-Lucent
– 60млн абонентов, аутентификация, управление данными
• neckermann.de
– 500к уникальных посетителей в день
• Paggo
– 25к транзакций в день, 25млн$/мес, мобильные платежи
• M1
– 1млн абонентов мобильной связи, Сингапур
•
здесь могла быть ваша реклама
Почта University of California Berkeley
•
•
•
•
•
•
70,000 аккаунтов в 39 доменах
20,000 рассылок, 1.1 миллион подписчиков
4 миллиона сообщений в день
1 миллион принятых сообщений в день
120 поступающих сообщений в секунду
Акаунты, рассылки, greylisting и др.
•
http://www.mysql.com/customers/customer.php?id=497
Конфигурация (Berkeley)
•
•
10 машин с Cyrus (4 Гб ОЗУ)
На этих же машинах дата-ноды
•
sql-ноды на других машинах
– данные в памяти с бэкапом на диск
MYSQL_ACCOUNT_QUERY = ${lookup mysql \
{select a.* from calmail.account a, \
calmail.domain d \ where \ a.domain_id=d.id and \
a.localpart='${quote_mysql:$local_part}' and \
d.name='${quote_mysql:$domain}' and \
a.state='active';}}
cyrus: verify = false driver = manualroute transport = cyrus_lmtp
route_data = ${extract{host}{MYSQL_ACCOUNT_QUERY}{$value}fail}
Конфигурация кластера (Berkeley)
ndb_mgm> show
Connected to Management Server at: 192.168.1.15:1186
Cluster Configuration
--------------------[ndbd(NDB)]
10 node(s)
id=1 @192.168.3.1 (Version: 5.0.30, Nodegroup: 0)
id=2 @192.168.3.2 (Version: 5.0.30, Nodegroup: 0)
id=3 @192.168.3.3 (Version: 5.0.30, Nodegroup: 1)
id=4 @192.168.3.4 (Version: 5.0.30, Nodegroup: 1, Master)
id=5 @192.168.3.5 (Version: 5.0.30, Nodegroup: 2)
id=6 @192.168.3.6 (Version: 5.0.30, Nodegroup: 2)
id=7 @192.168.3.7 (Version: 5.0.30, Nodegroup: 3)
id=8 @192.168.3.8 (Version: 5.0.30, Nodegroup: 3)
id=9 @192.168.3.9 (Version: 5.0.30, Nodegroup: 4)
id=10 @192.168.3.10 (Version: 5.0.30, Nodegroup: 4)
[ndb_mgmd(MGM)] 2 node(s)
id=41 @192.168.1.15 (Version: 5.0.30)
id=42 @192.168.1.70 (Version: 5.0.30)
[mysqld(API)] 15 node(s)
id=21 @192.168.1.15 (Version:
id=22 @192.168.1.70 (Version:
id=23 @192.168.1.20 (Version:
id=24 @192.168.1.65 (Version:
id=25 @192.168.1.75 (Version:
id=26 @192.168.1.85 (Version:
id=31 @192.168.2.20 (Version:
id=32 @192.168.2.22 (Version:
id=33 @192.168.2.24 (Version:
id=34 @192.168.2.29 (Version:
id=37 @192.168.1.93 (Version:
id=39 @192.168.1.80 (Version:
id=61 @192.168.2.10 (Version:
id=62 @192.168.2.12 (Version:
id=63 @192.168.2.14 (Version:
5.0.30)
5.0.30)
5.0.30)
5.0.30)
5.0.30)
5.0.30)
5.0.30)
5.0.30)
5.0.30)
5.0.30)
5.0.30)
5.0.30)
5.0.30)
5.0.30)
5.0.30)
Особенности (Berkeley)
• set ipn = inet_aton(in_ip_addr);
– 4 байта, а не 15
• не используем блобы
– они приводят к неявному созданию скрытой
вспомогательной таблицы
• избегаем ENUM
– изменение ENUM – ALTER TABLE, что приводит к простою
• Не было незапланированного даунтайма за год работы
• Может масштабироваться до нагрузок в 500 раз
превышающих текущие
Заключение
• Кластером нельзя забивать гвозди!
• Пишите: [email protected], http://sqlinfo.ru/forum/