История изменений

Если говорить о 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. Кроме того создалось общее впечатление крайней нестабильности.

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. Кроме того создалось общее впечатление крайней нестабильности.

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. Кроме того создалось общее впечатление крайней нестабильности.