Архитектура 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. Есть ли среди отключившихся дата-нод по одной ноде из каждой группы?

– нет – продолжить работу (вторая часть выключится по правилу 1)– да – продолжить алгоритм.

3. Спросить арбитра.– арбитр недоступен – выключиться.– арбитр доступен, узнать присутствую ли я в текущей конфигурации?

• нет – выключиться• да – продолжить работу

Производительность• Дата-нода осуществляет выборку данных и поиск по

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> showConnected to Management Server at: 192.168.1.15:1186Cluster 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: 5.0.30)id=22 @192.168.1.70 (Version: 5.0.30)id=23 @192.168.1.20 (Version: 5.0.30)id=24 @192.168.1.65 (Version: 5.0.30)id=25 @192.168.1.75 (Version: 5.0.30)id=26 @192.168.1.85 (Version: 5.0.30)id=31 @192.168.2.20 (Version: 5.0.30)id=32 @192.168.2.22 (Version: 5.0.30)id=33 @192.168.2.24 (Version: 5.0.30)id=34 @192.168.2.29 (Version: 5.0.30)id=37 @192.168.1.93 (Version: 5.0.30)id=39 @192.168.1.80 (Version: 5.0.30)id=61 @192.168.2.10 (Version: 5.0.30)id=62 @192.168.2.12 (Version: 5.0.30)id=63 @192.168.2.14 (Version: 5.0.30)

Особенности (Berkeley)• set ipn = inet_aton(in_ip_addr);

– 4 байта, а не 15• не используем блобы

– они приводят к неявному созданию скрытой вспомогательной таблицы

• избегаем ENUM– изменение ENUM – ALTER TABLE, что приводит к простою

• Не было незапланированного даунтайма за год работы• Может масштабироваться до нагрузок в 500 раз

превышающих текущие

Заключение

• Кластером нельзя забивать гвозди!

• Пишите: rgbeast@sqlinfo.ru, http://sqlinfo.ru/forum/