|
Задавайте вопросы, мы ответим
Вы не зашли.
День добрый!
Захотели перейти на отказоустойчивый и производительный кластер MySQL. Выбрали NDB.
настроили. по желанию - три хоста на каждом по три ноды - MGM, NDB, API. перенесли базу, для каждой таблицы седалали сменили движок на NDBCLUSTER. в итоге тормоза почти в десять раз, mysqld во время выполнения "ест" порядка 80% проца. и это при запросах с сайта от одного юзера.
начал я разбираться, на одном из хостов сдела всем таблицам обратно ALTER TABLE .. ENGINE=MyISAM - леатет как ракета, проц не ест. обратно в кластер - обратно тормоза. как понял так оптимизировал конфиги, все равно медленно.
все делалось в первый раз, может где-то чо-то лишнее мешает?
база: порядка 50Mb
хосты: три по 2x2 Xeon, 2Gb ram
кусок из my.cnf
[NDBD DEFAULT]
NoOfReplicas=3
DataDir=/var/log/mysql
FileSystemPath=/var/lib/mysql-cluster
MaxNoOfAttributes=100000
IndexMemory=50M
MaxNoOfConcurrentOperations=100000
RedoBuffer=32M
[MYSQLD DEFAULT]
[NDB_MGMD DEFAULT]
DataDir=/var/lib/mysql-cluster
LogDestination=FILE:filename=/var/log/mysql
[TCP DEFAULT]
SendBufferMemory=2M
ReceiveBufferMemory=1M
[Computer]
Id=10
HostName=192.168.0.10
[Computer]
Id=20
HostName=192.168.0.20
[Computer]
Id=30
HostName=192.168.0.30
# Managment Servers
[NDB_MGMD]
Id=1
ExecuteOnComputer=10
[NDB_MGMD]
Id=2
ExecuteOnComputer=20
[NDB_MGMD]
Id=3
ExecuteOnComputer=30
# Storage Engines
[NDBD]
Id=4
ExecuteOnComputer=10
[NDBD]
Id=5
ExecuteOnComputer=20
[NDBD]
Id=6
ExecuteOnComputer=30
# MySQL Clients
[MYSQLD]
Id=7
ExecuteOnComputer=10
[MYSQLD]
Id=8
ExecuteOnComputer=20
[MYSQLD]
Id=9
ExecuteOnComputer=30
Неактивен
Сначала отступление - Ваша конфигурация не отказоустойчива. Из трех нод, одна будет текущим менеджером. Если ее выключить, весь кластер в данной конфигурации отключится. Это связано с тем, что данная нода содержит всю информацию (так как NoOfReplicas=3, то каждая нода содержит всю инфу), если кластер ее не видит - фактически произошло разделение на два кластера (каждый из которых может работать), при этом выживает та часть, на которой менеджер.
Неактивен
По производительности. Посмотрите значение переменной engine_condition_pushdown
Она должна быть ON, иначе все WHERE отрабатываются только на SQL-ноде. Пусть есть запрос SELECT * FROM x WHERE условие. Алгоритм такое
1. Если engine_condition_pushdown=off, то действия А
2. В противном случае, если условие достаточно простое и может быть выполнено на датаноде (например num>10 или s=11, но не sin(x) < 0.5), то действия B, иначе действия A
Действия A
A1 MySQL нода запрашивает всю таблицу с датанод (она ничего не знает о физическом расположении на том же сервере), запрашивает по 1/3 данных с каждой ноды
A2 Дата ноды передают по 1/3 таблицы каждая по сети MySQL-ноде
A3 SQL-нода накладывает условие
Действия B
B1 MySQL нода запрашивает данные с датанод, передавая условие
B2 Дата ноды на своей 1/3 каждая проверяет условие и выдает соответствующие строки
Понятно, что действия A значительно медленнее, чем B обычно. Кроме того, все JOIN выполняются на SQL-ноде, можете представить себе алгоритм действий (заодно, используя EXPLAIN). Поэтому, скажем, если у Вас форум типа данного или веб-система с произвольной сложности запросами, то прямой перенос на кластер не даст выйгрыша в производительности.
См. также тему http://sqlinfo.ru/forum/viewtopic.php?id=140
Неактивен
1. по отступлению: не понимаю почему вылетит весь кластер - пускай на всех трех хостах запущены ndb_mgmd и ndbd, нода 1 NDB-master на первом хосте выходит из строя, на оставшихся двух хостах есть управляющие серверы, которые выдадут master'а другой ноде. я проверял эту ситуацию убиванием процессов ndbd и ndb_mgmd - все нормально продолжало работать.
2. Извиняюсь, в посте пропустил кусок из my.cnf там есть в секции [mysqlsd] engine-condition-pushdown=1
я новичок в этом деле, а есть ли разница между engine_condition_pushdown=ON и engine-condition-pushdown=1?
что это и для чего я знаю, но мне встречалось именно второе написание - engine-condition-pushdown=1
Неактивен
1. возможно Вы убивали их последовательно, нужно выдернуть сетевой кабель или отправить машину в ребут.
Причина простая - пусть есть 3 компа. Теперь Вы разделяете на 2 части, которые друг друга не видят. Должен быть алгоритм, который в таком случае не допустит работу обоих частей, чтобы не было ситуации split brain. Алгоритм простой - выключится кластер, который не видит текущего арбитра. То, что на других есть менеджмент-нода не поможет, так как смена арбитра не происходит, если кроме арбитра исчезли дата-ноды, содержащие полную информацию кластера.
2. да, =1 правильно. Посмотрите свои запросы с помощью EXPLAIN. Используется ли реально pushdown condition для них?
Неактивен
2. вывод EXPLAIN
+----+-------------+----------+-------+---------------+------+---------+------+------+-----------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+----------+-------+---------------+------+---------+------+------+-----------------------------------+
| 1 | SIMPLE | Projects | range | id | id | 4 | NULL | 1 | Using where with pushed condition |
+----+-------------+----------+-------+---------------+------+---------+------+------+-----------------------------------+
используется pushdown condition...
попробую поискать медленные запросы и их посмотреть
Неактивен
Запрос, который Вы привели может быть медленным только в случае, если его результат применения условия на id большой и долго передается по сети. Иногда помогает заменить SELECT * на SELECT перечень_используемых_полей
Наибольшую опасность представляют запросы со сложным WHERE и с JOIN
Неактивен
разрешилось дело: у заказчика индексов на таблицвх не было, добавил индексов - все залетало только так 
Неактивен
Объяснение почему приведенная Вами конфигурация неотказоучтойчива в статье http://webew.ru/articles/252.webew
Неактивен
