mysql replication, ndb cluster, может что-то другое... нужны советы..

12
Romka_Kharkov
На сайте с 08.04.2009
Offline
485
#11
madoff:
http://www.percona.com/doc/percona-xtradb-cluster/index.html - На читай там всё написано.

NDB - не Юзал да и чёт сильно не охота. Может позже если понадобится, и то без тестов не полезу на неё :) - а percona-xtradb вроде бы не плохо себя показывает.

Буду читать... в NDB меня смутила одна штука , не знаю пока как тут реализовано, но все же:

Как собрать 10 серверов и настроить их к менеджмент ноде... все понятно, вопрос в том, как обеспечить отказоустойчивость этой менеджмент ноды, ведь она получается одна и фактически от нее зависит кластеризация, а если она упала? кто потом разберется как должны быть данные, где новые, где старые, при беседе с тем же Андрейкой, он упоминал о конструкции с двумя менеджмент нодами, но как-то я или не понял или не нашел где читать, две менеджмент ноды могут друг друга дублировать в случае падения? Т.е на API концах можно указать 2 менеджмент ноды и оно там само определится к какой подключится если одна мертва?

---------- Добавлено 17.07.2013 в 13:40 ----------

netwind:
Но у вас же там, судя по другим размышлениям, объемы базы небольшие.

С этим ничего подозрительного - все описано. Слишком упрощенный и пессимистический подход. И автора уже забанили.
Там есть скрипт подсчитывающий по текущей базе, сколько понадобится памяти в NDB. Причем, неидексированные колонки таки можно хранить на диске.

Верно, данных не много там и 100 метров наверное не наберется... но это как бы не совсем меняет суть, хочется знать будущее :D :D :D как обычно :) По этому и хочется понимать к чему идем... а то сегодня 100 метров завтра 100 гиг, а решение уже не подойдет выходит....

Есть около 15.000 ipv4 !!! (http://onyx.net.ua/price.php#ipv4) Качественный хостинг с 2005 года - лучшее клиентам! (http://onyx.net.ua/)
N
На сайте с 06.05.2007
Offline
419
#12

Romka_Kharkov, на практике дублировать управляющую ноду не обязательно. Кластер будет продолжать обслуживать запросы нормально и без нее.

Вот sql-ноды можно и продублировать. То есть минимальная отказоустойчивая схема должна содержать хотя бы три компьютера :

1. управляющая нода

2. ndb-нода с данными первая. sql первый

3. ndb-нода с данными вторая . sql дублирующий.

(Честно говоря, не помню почему нужно выносить управляющую отдельно. что-то неочевидное там.)

Цели разработки mysql cluster были таковы, что любой компонент можно продублировать неоднократно, поэтому можно и их несколько держать.

Как вы там в приложении сделаете подключения в двум серверам - проблемы вашего приложения. К сожалению, mysql cluster ничего особенного для этой цели не предоставляет.

Один из простых вариантов запускать sql-ноду прямо на вебсервере.

Кнопка вызова админа ()
Romka_Kharkov
На сайте с 08.04.2009
Offline
485
#13
netwind:
Romka_Kharkov, на практике дублировать управляющую ноду не обязательно. Кластер будет продолжать обслуживать запросы нормально и без нее.
Вот sql-ноды можно и продублировать. То есть минимальная отказоустойчивая схема должна содержать хотя бы три компьютера :
1. управляющая нода
2. ndb-нода с данными первая. sql первый
3. ndb-нода с данными вторая . sql дублирующий.

(Честно говоря, не помню почему нужно выносить управляющую отдельно. что-то неочевидное там.)
Цели разработки mysql cluster были таковы, что любой компонент можно продублировать неоднократно, поэтому можно и их несколько держать.

Как вы там в приложении сделаете подключения в двум серверам - проблемы вашего приложения. К сожалению, mysql cluster ничего особенного для этой цели не предоставляет.
Один из простых вариантов запускать sql-ноду прямо на вебсервере.

Спасибо, буду еще думать и думать :D

12

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий