Назад | Перейти на главную страницу

Текущая установка максимального CPU. Нужна помощь в разработке архитектуры AWS и кластеризации MySQL с помощью экземпляров AWS RDS

Моя компания управляет корзиной электронной коммерции среднего размера (30 000–50 000 уникальных просмотров в месяц), используя X-Cart в качестве серверной части. Мы занимаемся переработкой и обновлением нашего внутреннего программного обеспечения. У нас возникли проблемы с нашим текущим сервером с максимальным значением ЦП из MySQL. У нас есть несколько медленных запросов, над исправлением которых мы работаем, но нам нужно перейти на новую инфраструктуру из нашей текущей выделенной настройки. Прямо сейчас у нас есть RHEL - AMD 2.2ghz 8 core, 31 Gig RAM и rackspace.

Текущий план миграции - перейти на AWS. Сейчас я думаю направить весь трафик по маршруту 53 в AWS Load Balancer. Оттуда запустите Apache и PHP на m3.xlarge, X-Cart на m3.xlarge, MySQL на c4.2xlarge (31 ECU, 8 ядер с двойной дополнительной вычислительной мощностью). Я планирую использовать образы AMI и корзину S3 для хранения настроек сервера для условий автоматического масштабирования. Я сохраню эту настройку в отдельной зоне для автоматического масштабирования, если это необходимо.

Вот где я запутался.

Есть ли преимущества в производительности для создания кластера MySQL.

Нет, если это конфигурация ведущий / ведомый.

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

Насколько я понимаю, я могу создать Мастера и Рабов. Подчиненные устройства могут быть настроены только для чтения или записи, и я также могу иметь резерв в другой зоне на случай сбоев или отключений.

Вы можете настроить столько мастеров и ведомых устройств, сколько захотите, в зависимости от того, с какой сложностью вы готовы справиться.

Какое повышение производительности я должен ожидать от создания ведомого устройства чтения.

Невозможно сказать без информации о количестве операций чтения, которые в настоящее время обслуживает ваша база данных.

Я планирую получить экземпляр с высоким ЦП для базы данных, могу ли я масштабироваться с меньшими объемами?

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

Прежде чем вам потребуется масштабировать свою БД, вы можете масштабировать свой веб-уровень, уровень приложения, вы можете добавить сервер memcached для кэширования общих запросов к базе данных, вы можете настроить индексацию своей базы данных и т. Д.

По моему опыту, кластеризация баз данных для повышения производительности, а не для обеспечения избыточности, не является распространенным сценарием.