-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Высоконагруженный проект (10мл. хостов в сутки) + mysql cluster
- Автор темы 440hz
- Дата начала
svetasmirnova
маленький монстрик
А ссылку можно где это утверждается?
siv
Новичок
Вот она:
http://bugs.mysql.com/bug.php?id=32896
Сам наткнулся на такой же косяк. На 6.3 все гуд. Если реально это работает на 7-ке - было бы просто супер.
http://bugs.mysql.com/bug.php?id=32896
Сам наткнулся на такой же косяк. На 6.3 все гуд. Если реально это работает на 7-ке - было бы просто супер.
svetasmirnova
маленький монстрик
Ну там же написано, что 6.x binaries работают нормально в том числе и на 7-ке. Так что какой-то workaround есть. Или как в последнем комментарии.
А вообще FreeBSD в списке supported platform для кластера нет. http://www.mysql.com/support/supportedplatforms/cluster.html Для обычного сервера только FreeBSD 6 поддерживается, поэтому наличие каких-то косяков с 7 не удивительно к сожалению.
А вообще FreeBSD в списке supported platform для кластера нет. http://www.mysql.com/support/supportedplatforms/cluster.html Для обычного сервера только FreeBSD 6 поддерживается, поэтому наличие каких-то косяков с 7 не удивительно к сожалению.
dadoc
Новичок
fixxxer
А как вы измеряли производительсноть? Я вот видел benchmark который показывает обратное.
http://www.kernel.org/pub/linux/kernel/people/npiggin/sysbench/
А как вы измеряли производительсноть? Я вот видел benchmark который показывает обратное.
http://www.kernel.org/pub/linux/kernel/people/npiggin/sysbench/
Ага, тест с kernel.org.
А вот тест с freebsd.org:
http://people.freebsd.org/~kris/scaling/os-mysql.png
Очевидно, что специалист по linux настроит его более грамотно, чем Freebsd, и наоборот, так что на такие тесты ориентироваться нечего.
Впрочем, я и не говорил о сравнении линукса и бсд. Как уже понятно, все зависит от прямоты рук администратора. А вот сравнение 6-ки и 7-ки - вот оно там же <http://people.freebsd.org/~kris/scaling/mysql.html> и есть:
http://people.freebsd.org/~kris/scaling/mysql-freebsd.png
А вот тест с freebsd.org:
http://people.freebsd.org/~kris/scaling/os-mysql.png
Очевидно, что специалист по linux настроит его более грамотно, чем Freebsd, и наоборот, так что на такие тесты ориентироваться нечего.
Впрочем, я и не говорил о сравнении линукса и бсд. Как уже понятно, все зависит от прямоты рук администратора. А вот сравнение 6-ки и 7-ки - вот оно там же <http://people.freebsd.org/~kris/scaling/mysql.html> и есть:
http://people.freebsd.org/~kris/scaling/mysql-freebsd.png
440hz
php.ru
все пашет как часы. нагрузка около лимона хитов в сутки. отвечают 2 ноды. мастер(nginx) тока пробрасывает.
Код:
master(root):/var/log/nginx#>uname -a
FreeBSD master.trafficshop.com 7.0-RELEASE FreeBSD 7.0-RELEASE #1: Thu Sep 4
17:36:59 CEST 2008 [email]440hz@master.trafficshop.com[/email]:/usr/obj/usr/src/sys/TORNADO amd64
master(root):/var/log/nginx#>ndb_mgm -e show
Connected to Management Server at: 78.140.142.21:1186
Cluster Configuration
---------------------
[ndbd(NDB)] 2 node(s)
id=10 @78.140.142.20 (Version: 5.1.26, Nodegroup: 0, Master)
id=11 @78.140.142.23 (Version: 5.1.26, Nodegroup: 0)
[ndb_mgmd(MGM)] 1 node(s)
id=1 @78.140.142.21 (Version: 5.1.26)
[mysqld(API)] 4 node(s)
id=20 @78.140.142.20 (Version: 5.1.26)
id=21 @78.140.142.21 (Version: 5.1.26)
id=22 @78.140.142.22 (Version: 5.1.26)
id=23 @78.140.142.23 (Version: 5.1.26)siv
Новичок
Тогда вопрос по сборке этого решения: mysqld с ndb собирался из портов или из сырцов?
Тестирую я тут mysql с ndb и портов - много нареканий появляется: проблемы с добавлением data nod с rolling restart.... (отваливается весь кластер) В ndb_mgm не пашет report (а очень бы хотелось). И самое главное - не наблюдаю mtndb. А вот это уже важно
ъ\
Из сырцов собираю - gmake какую-то ересь несет... Не поборол еще.
Тестирую я тут mysql с ndb и портов - много нареканий появляется: проблемы с добавлением data nod с rolling restart.... (отваливается весь кластер) В ndb_mgm не пашет report (а очень бы хотелось). И самое главное - не наблюдаю mtndb. А вот это уже важно
ъ\Из сырцов собираю - gmake какую-то ересь несет... Не поборол еще.
440hz
php.ru
все из портов.
делал стоп ноды и потом запуск. работает. валил ноду ресетом. кластер и нода нормально поднимается. больше не эксперементировал.
а так очень хорошее впечатление.
были нарекания с параметрами старта. подкрутил некоторые переменные. все запахало.
-~{}~ 25.02.09 15:00:
делал стоп ноды и потом запуск. работает. валил ноду ресетом. кластер и нода нормально поднимается. больше не эксперементировал.
а так очень хорошее впечатление.
были нарекания с параметрами старта. подкрутил некоторые переменные. все запахало.
-~{}~ 25.02.09 15:00:
это ты о чем?
Код:
master(root):/usr/backup#>ndb_mgm
-- NDB Cluster -- Management Client --
ndb_mgm> help
---------------------------------------------------------------------------
NDB Cluster -- Management Client -- Help
---------------------------------------------------------------------------
HELP Print help text
HELP COMMAND Print detailed help for COMMAND(e.g. SHOW)
SHOW Print information about cluster
START BACKUP [NOWAIT | WAIT STARTED | WAIT COMPLETED]
Start backup (default WAIT COMPLETED)
ABORT BACKUP <backup id> Abort backup
SHUTDOWN Shutdown all processes in cluster
CLUSTERLOG ON [<severity>] ... Enable Cluster logging
CLUSTERLOG OFF [<severity>] ... Disable Cluster logging
CLUSTERLOG TOGGLE [<severity>] ... Toggle severity filter on/off
CLUSTERLOG INFO Print cluster log information
<id> START Start data node (started with -n)
<id> RESTART [-n] [-i] [-a] Restart data or management server node
<id> STOP [-a] Stop data or management server node
ENTER SINGLE USER MODE <id> Enter single user mode
EXIT SINGLE USER MODE Exit single user mode
<id> STATUS Print status
<id> CLUSTERLOG {<category>=<level>}+ Set log level for cluster log
PURGE STALE SESSIONS Reset reserved nodeid's in the mgmt server
CONNECT [<connectstring>] Connect to management server (reconnect if already connected)
QUIT Quit management client
<severity> = ALERT | CRITICAL | ERROR | WARNING | INFO | DEBUG
<category> = STARTUP | SHUTDOWN | STATISTICS | CHECKPOINT | NODERESTART | CONNECTION | INFO | ERROR | CONGESTION | DEBUG | BACKUP
<level> = 0 - 15
<id> = ALL | Any database node id
For detailed help on COMMAND, use HELP COMMAND.
DIS
Новичок
Опа... у меня вопросы к автору темы.
1. Можно поднять mysqlcluster на 2-х тачках так, чтобы иметь и отказоустойчивость. т.е. я не понял можноли поднимать менеджера на обоих машинах? и как организовать передачу от одного менеджера другому?
2. Все таблицы в базах должны быть ndb ?
3. Поговаривают, что некоторые запросы на кластере выполняются медленнее, чем на отдельном серваке. не сталкивались?
спасибо.
1. Можно поднять mysqlcluster на 2-х тачках так, чтобы иметь и отказоустойчивость. т.е. я не понял можноли поднимать менеджера на обоих машинах? и как организовать передачу от одного менеджера другому?
2. Все таблицы в базах должны быть ndb ?
3. Поговаривают, что некоторые запросы на кластере выполняются медленнее, чем на отдельном серваке. не сталкивались?
спасибо.
svetasmirnova
маленький монстрик
DIS
Я, конечно, не автор темы, но тем не менее:
1. Можно:
connect-string="nodeid=2,myhost1:1100,myhost2:1100,192.168.0.3:1200"
Будет соединяться с первым живым.
Подробно тут: http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-connectstring.html
2. Нет, но надо понимать, что не-NDB таблицы будут видны только тому mysqld, который их создал. Плюс будут проблемы с областью видимости в случае использования одинаковых имён: когда NDB-таблица будет скрывать локальную.
3. Вот тут, например, почитайте: http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-limitations-performance.html
Я, конечно, не автор темы, но тем не менее:
1. Можно:
connect-string="nodeid=2,myhost1:1100,myhost2:1100,192.168.0.3:1200"
Будет соединяться с первым живым.
Подробно тут: http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-connectstring.html
2. Нет, но надо понимать, что не-NDB таблицы будут видны только тому mysqld, который их создал. Плюс будут проблемы с областью видимости в случае использования одинаковых имён: когда NDB-таблица будет скрывать локальную.
3. Вот тут, например, почитайте: http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-limitations-performance.html
440hz
php.ru
1. отказоустойчивость. когда нода падает мне нужна работающая БД и система целиком. сейчас есть одно узкое место в системе это балансер нагрузки. если упадет он, то вся система встанет, но это решается дублирующим сервером, хотя в данном случае нужно ручное вмешательство.
2. на счет производительности не думал сильно, но у меня много простых быстрых запросов и я думаю, что кластер со своим хранением БД в памяти, как раз мне подходит, а все сложные расчеты вынесены в отдельные MyISAM БД на других серверах и уже сами результаты кладутся в кластер для быстрых выборок. имеем большую избыточность, но зато большую производительность при выборках. так же при проектировании базы было учтены особенности проекта и многие другие нюансы, т.е. я потратил месяц только на проектирование системы и уже только потом приступил к кодированию, чему особенно рад.
DIS
Новичок
насчёт ручного вмешательства - heartbeat..
-~{}~ 26.02.09 11:02:
поделюсь с тем, что есть у нас...
действующий сайт. нагрузка выросла до 100 000 посетителей / 1 млн. хитов / 12 млн запросов http
много данных - 100 Гб и постоянно увеличивается.
постоянные апдейты по табличкам из которых идут выборки.
что нам дали: два мощных сервака (+ два коммутатора) и дисковый массив 1Тб.
задача - балансировка и отказоустойчивость.
синхронизация данных не подходит из-за особенностей кеширования и постоянной заливки достаточно больших объёмов данных на сайт и в базу.
рассмотрели несколько вариантов:
2 идентичные взаимозаменяемые ноды с общим массивом.
Система подчти (mysql cluster не реализовывали) была реализована, где балансировку можно было осуществлять различными способами (DNS, ngix, mod_backhand).. Но всё упёрлось в возможность совместного доступа к массиву. Для этого была использована ORACLE FILE SYSTEM.. под нагрузкой падали обе ноды.. просто зависали и всё тут.. никаких ошибок не писалось.. бились-бились, да отдали на аудит.. заключение как мы и думали.. нужно использовать другую файловую систему, которая стоит 20 т $.
зажали....
как итог решили разделить http и mysql на 2 сервера.
но на http так же установлен и настроен мускуль но не запущен, а на mysql настроены http, но не запущены.
и с помощью heartbeat можно переводить все сервисы на одну ноду, паралельно подключая нужные разделы массива.
итог:
реализована и балансировка нагрузки и отказоустойчивость с помощью 2-х серверов. не надо заморачиваться насчёт синхронизации данных - не создаётся дополнительная нагрузка. не надо оптимизировать базу и запросы под ndb - это могло занять много времени.
узкое место - массив, но у него надёжность 99,99 - каждый винт там зеркальный.
есть, конечно, и минус - немасштабируемая система.
всё это на сусьске....
-~{}~ 26.02.09 11:02:
поделюсь с тем, что есть у нас...
действующий сайт. нагрузка выросла до 100 000 посетителей / 1 млн. хитов / 12 млн запросов http
много данных - 100 Гб и постоянно увеличивается.
постоянные апдейты по табличкам из которых идут выборки.
что нам дали: два мощных сервака (+ два коммутатора) и дисковый массив 1Тб.
задача - балансировка и отказоустойчивость.
синхронизация данных не подходит из-за особенностей кеширования и постоянной заливки достаточно больших объёмов данных на сайт и в базу.
рассмотрели несколько вариантов:
2 идентичные взаимозаменяемые ноды с общим массивом.
Система подчти (mysql cluster не реализовывали) была реализована, где балансировку можно было осуществлять различными способами (DNS, ngix, mod_backhand).. Но всё упёрлось в возможность совместного доступа к массиву. Для этого была использована ORACLE FILE SYSTEM.. под нагрузкой падали обе ноды.. просто зависали и всё тут.. никаких ошибок не писалось.. бились-бились, да отдали на аудит.. заключение как мы и думали.. нужно использовать другую файловую систему, которая стоит 20 т $.
зажали....
как итог решили разделить http и mysql на 2 сервера.
но на http так же установлен и настроен мускуль но не запущен, а на mysql настроены http, но не запущены.
и с помощью heartbeat можно переводить все сервисы на одну ноду, паралельно подключая нужные разделы массива.
итог:
реализована и балансировка нагрузки и отказоустойчивость с помощью 2-х серверов. не надо заморачиваться насчёт синхронизации данных - не создаётся дополнительная нагрузка. не надо оптимизировать базу и запросы под ndb - это могло занять много времени.
узкое место - массив, но у него надёжность 99,99 - каждый винт там зеркальный.
есть, конечно, и минус - немасштабируемая система.
всё это на сусьске....