Как лучше сделать серверную архитектуру для HiLoad сайта?
Суть такая: имеется сайт, посещаемость на котором растет еженедельно. Для аналитики собираются большие данные о логах действий пользователя на сайте.
Сейчас это все сделано на 1-м сервере, БД MySQL. Сама БД в сжатом виде занимает 500 мегабайт, в распакованном 8 Гб.
Чтобы загрузить дамп БД на сервер, приходится ждать часа 4-5.
В этой базе есть несколько таблиц, в которых содержатся логи. Так вот они занимают львиную долю (7,5 Гб).
Нагрузка на сервер растет, уже были сбои по жестким дискам.
Что можно использовать, чтобы увеличить производительность сайта? его отказоустойчивость?
Я вижу решение сделать так: таблицы с логами убрать из БД, взять отдельный сервер, развернуть там PgSQL и туда писать все логи. Картинки тоже разместить на отдельном сервере, либо взять просто хранилище под картинки. БД MySQL реплицировать на отдельный сервер в режиме master-master. Но как сделать так, чтобы при отказе одного сервера все запросы шли на другой?
В вашей схеме не хватает балансировщика который будет следить кто из мастеров умер и переключать на другой.
Для примера: habrahabr.ru/company/bitrix/blog/146490
Сами используем pgsql с wal логами (у нас старая версия пг), в новой версии тестируем слонов и может быть скоро перейдем на них
По логам: вариантов много, кроме уже озвученных могу добавить:
1. Использовать AMQP (rabbitmq + федерация) и федерируйте логи куда угодно на любой сервер, там на принимающем сервере можете уже писать куда угодно можно даже "на лету" что-то агрегировать и т.п.
2. Использовать Scribe и им гнать сообщения в лог на любой удобный сервер сборщик-агрегатор
Оба решения позволяют доставлять сообщения в лог и в случае недоступности одного сервера-приемника пере-доставить на резервный. Писать можно куда угодно, можете в mongodb, можете в mysql+tokudb (у нее скорость работы на запись отличная и место можно за счет сжатия сэкономить)
По поводу HA: перенаправление запросов в случае отказа одного сервера, тоже много вариантов:
1. Дополнительный балансировщик перед серверами обрабатывающими запросы, nginx, haproxy и т.д. (но тут момент - этот балансировщик станет SPOF)
2. Использовать решения, например heartbeat и при выпадение сервера - переподнимать на резервном интерфейс и тушить на первом (спустя небольшое время все запросы пойдут на новый сервер)
Логи не устаревают? Я в плане, может быть имеет смысл удалять логи, старше 1 месяца, или дампить их и упаковывать. А дальше по крону, скажем, удалять излишки.
Для логов и аналитики, выгодно использовать NoSql ту же MongoDB у нее хорошая производительность на запись, если транзакции не так важны (что как правило справедливо для аналитики). Для репликации БД можно использовать MySql Galera habrahabr.ru/post/253869
Ну и запросы между серверами в зависимости от доступности и нагруженности умеет распределять Nginx.
