Добро пожаловать, Гость. Пожалуйста авторизуйтесь здесь.
FGHIGate на GaNJa NeTWoRK ST@Ti0N - Просмотр сообщения в эхоконференции RU.LINUX
Введите FGHI ссылку:


Присутствуют сообщения из эхоконференции RU.LINUX с датами от 24 Jan 02 06:01:34 до 18 Jun 24 11:25:53, всего сообщений: 8487
Ответить на сообщение К списку сообщений Предыдущее сообщение Следующее сообщение
= Сообщение: 944 из 8487 ========================================== RU.LINUX =
От   : Alexey Vissarionov               2:5020/545         27 Feb 14 12:22:44
Кому : Sergey Anohin                                       27 Feb 14 12:22:44
Тема : MySQL-Cluster
FGHI : area://RU.LINUX?msgid=2:5020/545+530f0980
На   : area://RU.LINUX?msgid=2:5034/10.1+530ee233
= Кодировка сообщения определена как: CP866 ==================================
Ответ: area://RU.LINUX?msgid=2:5034/10.1+53102c48
Ответ: area://RU.LINUX?msgid=2:5034/10.1+53102cb8
==============================================================================
Доброго времени суток, Sergey!
27 Feb 2014 10:59:00, ты -> All:

SA> Из чего лучше сооpудить Load-Balanser для сабжа? Я так понимаю
SA> есть heartbeat, ldirectord, mysql-proxy, сpедства днс, и дpугие.
SA> Как пpавильно выбpать нужное и что лучшее (быстpота, надежность)?

А что именно нужно - быстpота или надежность? Учти, что "или" в данном случае исключающее: увеличивая надежность, ты теряешь производительность, а повышая производительность снижаешь надежность.

Если речь зашла о распределении нагрузки - ты уперся в производительность. Прежде, чем заниматься сабжестроительством:

0. Убедись в том, что БД используется исключительно в качестве хранилища - то есть, никаких функций, триггеров итд.

1. Посмотри, какие запросы создают максимальную нагрузку (slow query log) и сколько их среди всех запросов. Также полезно посмотреть количество запросов, модифицирующих базу (update, insert, alter итд): если их заметно меньше, чем select'ов - считай, что тебе повезло (как, впрочем, и 99% пользователей).

В зависимости от результатов исследования:

0. Если используются функции - выноси их за пределы базы, в приложения: и нагрузку снизишь, и обслуживание всей этой системы упростишь.

1. Если преобладают select'ы - поднимай второй сервер и настраивай репликацию, после чего на первом сервере можно будет использовать в качестве хранилища файлов БД (только не смейся!) RAID-0 из 3...4 SSD. Да, именно stripe. Да, без избыточности. Да, из ненадежных SSD. Ибо его задача - обеспечить максимальную скорость работы с базой, а когда оно сдохнет (предусмотри внезапность этого, чтобы у тебя хотя бы запасной набор SSD на полочке лежал), ты поднимешь новый сервер, взяв данные с вторичника. Ясен пень, на вторичнике подход должен быть полностью противоположным - в частности, рекомендую собрать RAID-6 из хороших жестких дисков.

2. Если база постоянно модифицируется - поднимаем два сервера (есть кое-какие платформозависимые нюансы) и настраиваем репликацию master-master, после чего объединяем их посредством clusterip.

3. Если нагрузка совсем запредельная... не, в таких случаях я бесплатно не консультирую :-)


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii

... Как мяукнется - так и отгавкнется
--- /bin/vi
* Origin: http://openwall.com/Owl/ru (2:5020/545)

К главной странице гейта
Powered by NoSFeRaTU`s FGHIGate
Открытие страницы: 0.047731 секунды