Документ описывает архитектуру MySQL Cluster, акцентируя внимание на отказоустойчивости, производительности и преимуществах сотрудничества между MySQL и Sun Microsystems, завершившегося в 2008 году. В частности, рассматриваются аспекты избыточности данных, разбиения и хранения данных, а также механизмы автоматического восстановления и арбитража в кластерной среде. Приводятся примеры успешного применения технологии в крупных компаниях и подчеркиваются ключевые конфигурации для эффективной работы MySQL Cluster.

1. Архитектура MySQL Cluster Григорий Рубцов MySQL AB / Sun Microsystems

2. План доклада Архитектура Отказоустойчивость Производительность плюсы минусы Практика

3. Приобретение MySQL компанией Sun Сделка завершилась в 2008 году Sun и MySQL совместными усилиями сделают продукты и услуги ближе к заказчику. Корпоративная поддержка 24x7x3 6 5 географически ближе Больше поддерживаемых платформ Профессиональные услуги и обучение в России Обе компании твердо стоят на позициях Open Source Миссия Sun/MySQL: Сделать доступную каждому высококлассную СУБД .

4. Архитектура сервера MySQL

5. Общая архитектура кластера

6. Особенности архитектуры: Избыточность Данных NoOfReplicas (min: 2) SQL- нод mgm- нод (управляющих нод) Разбиение данных число долей равно числу дата-нод критерий разбиения – первичный хэш-индекс таблицы “ Shared nothing”, общая только сеть Транзакционность ( READ_COMMITTED )

7. Лицензия Две формы издания Community, 100% GPL Enterprise, коммерческий продукт с поддержкой ( MySQL Cluster Carrier Grade Edition) Исходный код общий MySQL Cluster 6.2 можно скачать, 6.2 - это версия ndb (не связана с MySQL 6 )

8. Открытый NDB API Позволяет обойти SQL- сервер или самому им быть http://dev.mysql.com/doc/ndbapi/en/

9. 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());

10. Хранение данных Фрагментация по первичному хэш-индексу Хранение в памяти и на диске (с версии 5.1) B-tree индексы – отдельные таблицы – также фрагментируются До 48 дата-нод Сеть должна быть быстрой (гигабит) Все соединения между нодами без авторизации и без шифрования

11. 6 нод, NoOfReplicas=2

12. Отказоустойчивость Возможность резервирования всего отсутствие единой точки отказа Не забудьте про резервирование сети два свича, по 2 сетевых карты Географическая распределенность : репликация кластеров Автоматическое восстановление дата-ноды

14. Арбитраж Фрагментация кластера может привести к двум потенциально работоспособным частям . « Split brain » - это плохо! Для этого есть арбитр ( mgm или sql- нода) выборы арбитра только после того, как все алгоритмы арбитража отработали ArbitratorRank=0 (never), 1 (high), 2 (low) при равном ArbitrationRank, min(nodeid)

15. Алгоритм арбитража Вижу ли я по крайней мере одну дата-ноду из каждой группы? нет – выключиться да – продолжить алгоритм Есть ли среди отключившихся дата-нод по одной из ноде из каждой группы? нет – продолжить работу (вторая часть выключится по правилу 1) да – продолжить алгоритм. Спросить арбитра. арбитр недоступен – выключиться. арбитр доступен, узнать присутствую ли я в текущей конфигурации? нет – выключиться да – продолжить работу

16. Производительность Дата-нода осуществляет выборку данных и поиск по btree- индексу в своем фрагменте Условие WHERE может выполняться на дата-ноде SET engine_condition_pushdown=1; только сравнения с константами age>27 OK (age – 27) > 0 плохо Используйте EXPLAIN EXTENDED + SHOW WARNINGS

17. Производительность Выполняются на SQL- ноде : WHERE, когда не работает pushdown ORDER BY JOIN Подзапросы Простые запросы – быстро и эффективно Не все составные запросы одинаково полезны Нельзя вслепую заменить MyISAM на NDB

18. Практика применения Alcatel-Lucent 60млн абонентов, аутентификация, управление данными neckermann.de 500к уникальных посетителей в день Paggo 25к транзакций в день, 25млн $/ мес, мобильные платежи M1 1млн абонентов мобильной связи, Сингапур здесь могла быть ваша реклама

19. Почта University of California Berkeley 70,000 аккаунтов в 39 доменах 20,000 рассылок, 1.1 миллион подписчиков 4 миллиона сообщений в день 1 миллион принятых сообщений в день 120 поступающих сообщений в секунду Акаунты, рассылки, greylisting и др. http://www.mysql.com/customers/customer.php?id=497

20. Конфигурация ( 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}

21. Конфигурация кластера ( 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: 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)

22. Особенности ( Berkeley ) set ipn = inet_aton(in_ip_addr); 4 байта, а не 15 не используем блобы они приводят к неявному созданию скрытой вспомогательной таблицы избегаем ENUM изменение ENUM – ALTER TABLE, что приводит к простою Не было незапланированного даунтайма за год работы Может масштабироваться до нагрузок в 500 раз превышающих текущие

23. Заключение Кластером нельзя забивать гвозди! Пишите: rgbeast@sqlinfo.ru, http://sqlinfo.ru/forum/