1 / 23

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

Архитектура MySQL Cluster. Григорий Рубцов MySQL AB / Sun Microsystems. План доклада. Архитектура Отказоустойчивость Производительность плюсы минусы Практика. Приобретение MySQL компанией Sun. Сделка завершилась в 2008 году

jackie
Télécharger la présentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  3. Приобретение MySQL компанией Sun Сделка завершилась в 2008 году Sun и MySQL совместными усилиями сделают продукты и услуги ближе к заказчику. Корпоративная поддержка 24x7x365 географически ближе Больше поддерживаемых платформ Профессиональные услуги и обучение в России Обе компании твердо стоят на позициях 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 сетевых карты • Географическая распределенность: • репликация кластеров • Автоматическое восстановление дата-ноды

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

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

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

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

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

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

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

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

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

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

More Related