Спасибо.
Один сервер mysql может обрабатывать 50-60 ГБ данных. Это действительно зависит от настройки вашей базы данных и от того, насколько сложными могут быть ваши запросы.
Я имею в виду, что вы можете заставить mysql летать, написав приложение, которое не присоединяется ... или вы можете заставить его сканировать, выполняя очень сложные запросы.
Я бы выбрал кластер, если в первую очередь вам нужно простое резервирование.
Редактировать математику кластерного барана
Используйте следующую формулу, чтобы определить объем оперативной памяти, который вам нужен на каждом узле хранения:
(Size of database * NumberofReplicas * 1.1) / Number of storage nodes
NumberofReplicas по умолчанию установлено на два. Вы можете изменить его в config.ini, если хотите. Так, например, для запуска базы данных объемом 4 ГБ на двух серверах с NumbeOfReplicas, установленным на два, вам потребуется 4,4 ГБ ОЗУ на каждом узле хранения. Для узлов SQL и узлов управления вам вообще не нужно много оперативной памяти. Чтобы запустить базу данных 4 ГБ на 4 серверах с NumberOfReplicas, установленным на два, вам потребуется 2,2 ГБ на узел.
Раньше ваша база данных должна была умещаться в памяти для использования кластера MySQL. Я считаю, что теперь ваши индексы должны умещаться в памяти, но данные могут быть привязаны к диску. Если у вас достаточно памяти на ваших серверах (вполне возможно, 64 ГБ), то все готово.
Кластер MySQL - это своего рода нишевый случай, и я думаю, что в большинстве случаев существуют лучшие решения проблем. Если вы дадите мне более подробную информацию, я отвечу тем же.
ответ на первый комментарий Кластер - нишевая вещь из-за ограничений памяти. Часто в случаях, когда требуется избыточность для чего-то большого, скорости нет. Аппаратные требования кластера чрезмерно высоки для обработки 5500 вставок строк RADIUS в день. Я бы посоветовал вам использовать шард в вашей настройке. Используйте кластер для текущих записей, а затем скопируйте их на обычный сервер с обычным резервным копированием и временем автономной работы / обслуживания для обработки исторических данных. Это обеспечит вам стабильность кластера, надежно гарантируя, что вы не потеряете никаких данных или не столкнетесь с простоями.