LINUX.ORG.RU
ФорумAdmin

Вопросы по кластеризации MySQL


3

2

Здравствуйте уважаемые форумчане. Хотел бы прояснить некоторые вопросы связанные с кластеризацией MySQL. Какие технологии кластеризации/резервирования/балансировки MySQL существуют? Имеется ввиду ndb-кластеризация, ha-технологии, отдельные движки-форки, типа MariaDB/Percona итд? В каких вариантах кластеризации СУБД и какими способами осуществляются следующие механизмы:

1. В кластере MySQL например с из 2,3... серверов все ноды работают одновременно, или работает главный сервер и в случае его падения стартует альтернативный?

2. Если одновременно работают все северы MySQL в кластере, значит ли это что происходит распределение нагрузки на все серверы в кластере? Что гарантирует распределение этой нагрузки? (Мыслю по аналогии с Hardware NLB [имея 2,3... ноды СУБД кластера, распределением нагрузки занимается NLB сервер, сами СУБД серверы в кластере нагрузку не разделяют])

3. Очевидно что если все севера MySQL в кластере работают одновременно, то файлы БД и журнал транзакций должны храниться на внешней системе хранения данных(что бы БД была доступна все MySQL серверам). Или же БД хранятся на MySQL серверах по отдельности но синхронизируется между собой по аналогии с данными на дисками в RAID массиве(примерное описание)?

4. Как осуществляется масштабирование кластера для увеличения производительности? Добавлением допольнительных MySQL серверов в кластер или нужна модернизация СХД? Что в большей степени влияет на производительность из выше перечисленного?

5. Как осуществлять резервирование БД из СХД без потери производительности, на отдельный раздел в самой СХД или желательно поставить отдельную СХД например на основе ленточных носителей?

6. Какой компьютер в сети должен заниматься резервированием БД (например я подключаюсь к кластеру и запускаю процесс резервирования или это желательно делать по расписанию средствами кластера, или отдельный сервер должен делать это что бы не нагружать производительность кластера)?

★★

Последнее исправление: ChAnton (всего исправлений: 1)

Если говорить о NDB:

1. В кластере MySQL например с из 2,3... серверов все ноды >работают одновременно, или работает главный сервер и в случае >его падения стартует альтернативный?

есть sql ноды и data ноды, работают «одновременно»

2. Если одновременно работают все северы MySQL в кластере, >значит ли это что происходит распределение нагрузки на все >серверы в кластере? Что гарантирует распределение этой >нагрузки? (Мыслю по аналогии с Hardware NLB [имея 2,3... ноды >СУБД кластера, распределением нагрузки занимается NLB сервер, >сами СУБД серверы в кластере нагрузку не разделяют])

Шлете запросы на разные sql ноды и нагрузка распределяется

3. Очевидно что если все севера MySQL в кластере работают >одновременно, то файлы БД и журнал транзакций должны >храниться на внешней системе хранения данных(что бы БД была >доступна все MySQL серверам). Или же БД хранятся на MySQL >серверах по отдельности но синхронизируется между собой по >аналогии с данными на дисками в RAID массиве(примерное >описание)?

Каждая sql нода хранит бинлоги у себя. У датанод тоже есть «бинлоги»

4. Как осуществляется масштабирование кластера для увеличения >производительности? Добавлением допольнительных MySQL >серверов в кластер или нужна модернизация СХД? Что в большей >степени влияет на производительность из выше перечисленного?

Красиво все выглядит только на картинках с оффсайта. Достаточно прочитать их форум чтобы понять что использовать это в продакшне нельзя. Мы однажды пробовали, в итоге оказалось что банальный master-slave постгрес по всем параметрам обгоняет 6 серверов mysql кластера на порядок(в наших запросах). Это если не учитывать что join в mysql кластер вообще неюзабельный по причинам производительности. Последние релизы с pushdown-join пофиксили только один конкретный случай join. Планировщик тоже работает не так как с innodb к примеру и даже при простых запросах по одной таблице индексы выбираются наобум. Вероятно можно пользоваться только если запросы - селекты по PK. Кроме того создалось общее впечатление крайней нестабильности.

ventilator ★★★
()
Последнее исправление: ventilator (всего исправлений: 2)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.