Архитектура My SQL Cluster Григорий Рубцов My SQL

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

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

Приобретение My. SQL компанией Sun • • • Сделка завершилась в 2008 году Sun и My. SQL совместными усилиями сделают продукты и услуги ближе к заказчику. – Корпоративная поддержка 24 x 7 x 365 географически ближе – Больше поддерживаемых платформ – Профессиональные услуги и обучение в России Обе компании твердо стоят на позициях Open Source Миссия Sun/My. SQL: Сделать доступную каждому высококлассную СУБД.

Архитектура сервера My. SQL

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

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

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

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

NDB API (пример) Ndb. Operation *my. Operation = my. Transaction->get. Ndb. Operation(my. Table); if (my. Operation == NULL) APIERROR(my. Transaction->get. Ndb. Error()); my. Operation->insert. Tuple(); my. Operation->equal("ATTR 1", i); my. Operation->set. Value("ATTR 2", i); if (my. Transaction->execute( Ndb. Transaction: : Commit ) == -1) APIERROR(my. Transaction->get. Ndb. Error());

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

6 нод, No. Of. Replicas=2

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

Арбитраж • Фрагментация кластера может привести к двум потенциально работоспособным частям. • «Split brain» - это плохо! • Для этого есть арбитр (mgm или sql-нода) – выборы арбитра только после того, как все алгоритмы арбитража отработали – Arbitrator. Rank=0 (never), 1 (high), 2 (low) – при равном Arbitration. Rank, 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 Подзапросы • Простые запросы – быстро и эффективно • Не все составные запросы одинаково полезны • Нельзя вслепую заменить My. ISAM на NDB

Практика применения • Alcatel-Lucent – 60 млн абонентов, аутентификация, управление данными • neckermann. de – 500 к уникальных посетителей в день • Paggo – 25 к транзакций в день, 25 млн$/мес, мобильные платежи • M 1 – 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)

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

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