Архитектура 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 можно скачать, это версия ndb (не связана с MySQL 6)
Открытый NDB API Позволяет обойти SQL-сервер или самому им быть
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 и др.
Конфигурация ( 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: :1186 Cluster Configuration [ndbd(NDB)] 10 node(s) (Version: , Nodegroup: 0) (Version: , Nodegroup: 0) (Version: , Nodegroup: 1) (Version: , Nodegroup: 1, Master) (Version: , Nodegroup: 2) (Version: , Nodegroup: 2) (Version: , Nodegroup: 3) (Version: , Nodegroup: 3) (Version: , Nodegroup: 4) (Version: , Nodegroup: 4) [ndb_mgmd(MGM)] 2 node(s) (Version: ) (Version: ) [mysqld(API)] 15 node(s) (Version: ) (Version: ) (Version: ) (Version: ) (Version: ) (Version: ) (Version: ) (Version: ) (Version: ) (Version: ) (Version: ) (Version: ) (Version: ) (Version: ) (Version: )
Особенности ( Berkeley ) set ipn = inet_aton(in_ip_addr); – 4 байта, а не 15 не используем блобы – они приводят к неявному созданию скрытой вспомогательной таблицы избегаем ENUM – изменение ENUM – ALTER TABLE, что приводит к простою Не было незапланированного даунтайма за год работы Может масштабироваться до нагрузок в 500 раз превышающих текущие
Заключение Кластером нельзя забивать гвозди! Пишите: