The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Настройка кластера MySQL (mysql database cluster replication)


<< Предыдущая ИНДЕКС Правка src / Печать Следующая >>
Ключевые слова: mysql, database, cluster, replication,  (найти похожие документы)
From: Михаил Сгибнев <mixa(@).dreamcatcher.ru> Date: 2006-09-12 09:51:47 Subject: Настройка кластера MySQL
Original

Введение

Кластерное решение на базе MySQL является отказоустойчивым, избыточным и масштабируемым решением для баз данных, основанным на открытых исходных текстах. Использование такой схемы позволяет достигнуть надежности в 99.999 %. В этой статье мы опишем процесс установки, настройки и тестирования кластера MySQL, состоящего из трех узлов.

Схема подключения

MySQL

Аппаратное обеспечение

Мы использовали четыре сервера Sun Ultra Enterprise, но процесс установки кластера на другой UNIX- или Linux-подобной системе будет отличаться очень незначительно.

Наши четыре машины относятся к одной из трех ролей:
  1. Хранилище (mysql-ndb-1 и mysql-ndb-2)
  2. API (mysql-api-1)
  3. Сервер управления и консоль управления (mgmt)
Обратите внимание, что узлы хранилища также явзяются API нодами, но API нода не является хранилищем. Узел API - полноправный член кластера, но он не хранит никаких данных кластера и его состояние (работает/не работает) не затрагивает целостность или доступность данных. Об этой ноде можно думать как о "клиенте" кластера. Приложения, такие как Web-сервер, установлены на ноде API и общаются с процессом MySQL, запущенным локально, именно этот процесс запрашивает данные от хранилищ. На хранилищах также могут быть установлены приложения, поскольку они совмещают в себе API ноды, но для промышленного применения такое совмещение нежелательно.

Программное обеспечение

Мы используем Sun Solaris 8 и mysql-max-4.1.9.

Мы использовали прекомпилированный пакет MySQL для Sun SPARC Solaris 8, вы должны использовать программное обеспечение в зависимости от используемой вами архитектуры, но в любом случае, необходимо использовать вариант "max".

Порядок действий

Шаг 1: После загрузки нод mysql-ndb-1 (192.168.0.33) и mysql-ndb-2 (192.168.0.34) устанавливаем и настраиваем MySQL: Не запускайте сервис!

Шаг 2: Установим сервер и консоль управления на mgmt (192.168.0.32): Файл config.ini содержит необходимую информацию для кластера: Запускаем сервер управления и проверяем его работу: Шаг 3: Конфигурируем MySQL на нодах mysql-ndb-1 (192.168.0.33) и mysql-ndb-2 (192.168.0.34): В данном случае файл конфигурации выглядит следующим образом: Запускаем сервисы и проверяем их работу: Если сервис не запустился, то просмотрите файл /usr/local/mysql/data/${HOSTNAME}.err и устраните проблему.

Шаг 4: Запускаем сервер и консоль управления, проверяем состояние кластера: Шаг 5: Создаем тестовую базу данных и проверяем корректность операций:

Создаем на хранилищах mysql-ndb-1 и mysql-ndb-2 тестовую базу: Вернитесь на хранилище mysql-ndb-1, и создайте простейшую таблицу с некоторыми значениями: Перейдите на ноду mysql-ndb-2 и проверьте доступность данных: Если у вас все получилось, то это хороший признак, хотя стоит учесть то, что на самом то деле данные могут и не скопироваться. В очередной раз напомню, что хранилище (mysql-ndb-2) также является и API-нодой и этот тест просто показывает, что данные в кластере можно восстановить. Для более наглядной демонстрации мы воспользуемся следующим тестом.

Убейте процесс NDB (ndbd) на хранилище (mysql-ndb-2) для того, чтобы имитировать отказ одной из нод. Сервер управления должен обнаружить отказ хранилища mysql-ndb-2 (192.168.0.34), но связь с API должна быть. В хранилище mysql-ndb-1 создайте еще одну таблицу: Перейдем на ноду mysql-ndb-2 и выполним следущую команду: Хранилище и сервер API являются независимыми приложениями, поэтому как только сервис хранилища ndbd будет запущен, данные будут среплицированы, что и будет продемонстрировано в следующем тесте.

Сперва перезапустите хранилище mysql-ndb-2: Затем, останавливаем хранилище на mysql-ndb-1, используя консоль управления или команду kill: После того, как хранилище на mysql-ndb-2 было перезапущено, необходимо убедиться в репликации данных: Тем самым мы убедились в репликации данных между хранилищами. Запускаем хранилище mysql-ndb-1: Шаг 6: Теперь мы добавим в кластер ноду API. Она является полноценным членом кластера, за исключением того, что на ней не запущен движок хранилища NDB. Данные на эту ноду не реплицируются и она выполняет только "клиентские" функции. Как правило, на такие ноды устанавливаются приложения, требующие для своей работы MySQL. Приложения обращается к серверу MySQL на localhost, а он, в свою очередь, обращается за данными к кластеру.

Сперва установим сервер MySQL для API ноды mysql-api-1 (192.168.0.35): Устанавливаем простой файл конфигурации /etc/my.cnf: Запускаем сервер MySQL: Выполним несколько запросов к таблицам, которые мы создали ранее: С помощью консоли управления убедимся, что API нода теперь доступна: Теперь наша конфигурация похожа на диаграмму, представленую в верхней части статьи.

Шаг 7: Теперь мы готовы проверить отказоустойчивость кластера, обслуживая запросы с API ноды:

С помошью сервера API ноды создадим тестовую базу данных и наполним ее неким содержимым: Вставим случайные данные в таблицу, руками или используя этот короткий сценарий: Выполняем запросы: Круто, работает. Теперь отключим серевой кабель от первого хранилища, чтобы вызвать аварию в кластере. Через несколько секунд консоль управления доложит об исчезновении ноды:
Для API ноды данные кластера все еще доступны? Подключим кабель обратно. Хранилище попытается подключиться обратно в кластер но, вероятно, будет отключен сервером управления, с появлением подобной ошибки (/var/lib/mysql-cluster/mdb_2_error.log): Перезапускаем процесс ndb и видим, как нода присоединяется к кластеру:

Разное


<< Предыдущая ИНДЕКС Правка src / Печать Следующая >>

Обсуждение [ RSS ]
  • 1, antono (?), 15:50, 25/06/2008 [ответить]  
  • +/
    А бенчмарки кто-нить делал?
    У меня на стомегабитной сети получилась производительность в 3-7 раз ниже чем у одной базы с InnoDB.
     
  • 2, Виталий (??), 23:43, 18/03/2010 [ответить]  
  • +/
    Кластерный Storage Engine имеет следующие ограничения(перечисляю не все):
    Количество атрибутов в таблице не может быть больше 128. Т.е. если у вас в таблице больше 128 полей - до свидания, работать не будет.
    Полнотекстовые индексы не поддерживаются.
    Внешние ключи (FOREIGN KEY) игнорируются.
    Размер одной записи (строки) в таблице не может превышать 8кбайт. При этом любое поле BLOB или TEXT занимает 264 байта
    Количество объектов в кластере (БД, таблицы, индексы) не может превышать 20320
    Имена объектов и таблиц, содержащие специальные символы не всегда корректно подхватываются другими узлами
    Вы не можете создавать индексы на поля типа TEXT и BLOB
    Поле типа BIT не может быть индексом иначе как в составном индексе (ни первичным ключём, ни уникальным и т.д.)
    Для каждой таблице возможно только одно поле с AUTO_INCREMENT

    Вам решать самим - стоит ли пользоваться этим сплошным недоразумением или всё-таки жить спокойно. Мой вывод - такой кластер будет работать только на небольших таблицах при небольшом размере БД, но тогда зачем вообще нужен кластер? На нагруженных и тяжёлых БД всё это работать не будет!

    Оптимизируйте структуру БД и запросы, создавайте индексы. Если же несмотря на всё это мощность MySQL вам не хватает и вы думаете о кластере, то лучше посмотрите в сторону PostgreSQL или Oracle.

     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру