Я хочу обновить свой сервер из-за высоких нагрузок mysql, вызывающих медлительность + всякий раз, когда в БД выполнялись процессы резервного копирования, БД была бы недоступна, поэтому мне нужно было какое-то решение. Мой текущий сервер - Opteron 2212 с 8 ГБ оперативной памяти.
Мой веб-хост предложил сервер с более низкой конфигурацией (Phenom Hexacore с 8 ГБ ОЗУ), но взять 3 сервера + балансировщик нагрузки ... они сказали, что это поможет в ситуациях с большим объемом трафика, а также поможет, когда один из серверов не получается, что будет резервный сервер.
При дополнительном запросе они сказали, что репликация mysql не будет настроена, потому что они взимают дополнительную плату за это, но все равно смогут настроить настройку, которая будет соответствовать моим потребностям.
Я не совсем уверен, будет ли достигнута моя цель обновления, если у меня будет 3 таких сервера и нет репликации mysql ... они не очень понимают, как они это настроили. Есть идеи относительно того, хорошее ли это решение и что я мог бы им предложить?
Пока я ценю Дальновидныйс перспектива и считают, что это имеет ценность, я бы предположил, что их единственный мотив может заключаться не только в том, чтобы заработать на вас деньги.
Похоже, это может предложить решение, близкое к идеальному или, по крайней мере, более профессиональное решение, чем то, что вы реализовали сейчас. Тем не менее, он все еще может быть переработан для ваших нужд. Отчасти это вопрос бизнеса. Оправданы ли дополнительные расходы?
Высокие нагрузки требуют дополнительных исследований. Риторически .. Это запросы на чтение? Можно ли их оптимизировать? Ваша схема оптимизирована? Если это запросы записи, вам может потребоваться масштабирование. В противном случае вы можете рассмотреть возможность архивирования данных, которые больше не нужны.
Распространенным решением для резервного копирования баз данных MySQL является использование подчиненного реликанта и последующее создание его моментального снимка, что предотвращает блокировку БД. Хотя возможной причиной является конфликт ввода-вывода, использование mysqldump или mysqlhotcopy часто приводит к некоторому уровню блокировки. Другие решения включают Xtrabackup. Скорее всего, ваше решение для резервного копирования можно существенно улучшить.
Хотя то, что они предлагают, безусловно, ближе к идеалу и лучше, чем то, что у вас есть сейчас, оправдано это или нет - решать вам. Скорее всего, вы сможете получить больше прибыли и сократить текущие расходы, улучшив то, что у вас есть сейчас, поскольку это укрепит вашу платформу для будущего роста.
Они хотят заработать на вас больше денег, это так просто.
Перво-наперво: создание резервной копии делает вашу БД недоступной? Либо у вас очень плохое решение для резервного копирования, либо у вас серьезные проблемы с вводом-выводом на сервере. Скорее всего, это ввод-вывод. Я бы сначала посмотрел, как это исправить. Если вы используете VPS, ваш хост может назначить вам необработанные сопоставления LUN вместо того, чтобы предоставлять вам виртуальный диск на общем абстрактном LUN.
Если они не собираются настраивать репликацию MySQL, то вы либо останетесь в одиночестве, либо получите за это целое состояние. Я не знаком с репликацией MySQL (только MSSQL), но предполагаю, что это нетривиальная задача, и ее должен выполнять кто-то, кто знает, что делает. Если вы не собираетесь дублировать свой SQL-сервер, а только ваш веб-сервер, то я не понимаю, как это поможет вашему сайту.
В-третьих, вы не предоставили нам никаких подробностей о базе данных, так что это всего лишь удар в темноте, но, возможно, есть места, которые вы можете оптимизировать в своей базе данных. Opteron 2212 и 8 ГБ ОЗУ - не медленная система. У нас 400 одновременных пользователей 18 часов в день, которые обрабатывают более 500 000 запросов в день на нашем портале, что приводит к 10 миллионам запросов к базе данных 30 ГБ, и он прекрасно работает на машине с аналогичными характеристиками. Хорошо спроектированные индексы могут сэкономить вам много денег, времени и головной боли.
Я думаю, что есть много других возможностей, на которые стоит обратить внимание, прежде чем принимать решение о выборе пути балансировки нагрузки, особенно если вы собираетесь кластеризовать серверы SQL. Однако есть один момент, в котором они правы: если один сервер выходит из строя, у вас действительно происходит мгновенное переключение при отказе (если ваш балансировщик нагрузки настроен правильно), но даже если у вас нет переключения при отказе, у вас есть резервные копии (отсюда первый пункт ) так что это, вероятно, не конец света.
Кажется, вы утверждаете, что источником проблем с производительностью является исключительно нагрузка с сервера mysql - хотя предлагаемое решение более эффективно справляется с нагрузкой HTTP, оно, похоже, ничего не делает для проблемы mysql. Вы уверены, что СУБД является причиной проблем, когда вы не делаете резервные копии?
Я не согласен с Farseeker - репликация mysql для получения согласованной резервной копии очень проста в настройке (простая репликация master-slave). На самом деле кажется пустой тратой не использовать преимущества потенциальной возможности балансировки нагрузки, но в сочетании с резервным копированием это сделало бы конфигурацию довольно сложной.
Вы должны иметь возможность выполнять резервное копирование на этой машине без блокировки базы данных.
? Вот это да. Как? Каждая СУБД, которую я использовал, потенциально может заблокироваться во время резервного копирования, включая Oracle и Sybase. Конечно, блокировка гораздо реже встречается в более поздних движках c-isam в MySQL, но она все еще существует.
Вы должны иметь возможность выполнять резервное копирование на этой машине без блокировки базы данных. Я бы посмотрел на другие варианты резервного копирования. Чем ты сейчас пользуешься?
Если ваша одновременная пользовательская нагрузка не является проблемой, балансировщик нагрузки + серверы доставят вам больше проблем, чем решений. В зависимости от использования вашей базы данных (какой тип ввода-вывода? В основном читает? В основном пишет?) Существует несколько способов оптимизации вашей базы данных. Репликацию MySQL настроить несложно, но я не думаю, что это решение вашей проблемы.
Вы упоминаете о большом количестве операций записи для веб-приложения, вы уверены, что это 65:35? Если у вас высокая нагрузка на MySQL, то ваша проблема не будет решена путем увеличения количества серверов, поскольку вы не можете легко распределять записи в базу данных без (обычно) серьезных модификаций вашего кода.
У вас есть несколько вариантов:
Оптимизируйте свою базу данных, как это предлагают другие ответы. Это означает, что убедитесь, что все данные правильно проиндексированы.
Кешируйте свои результаты на веб-сервере. Для этого существуют разные стратегии, одна из самых простых - записать сгенерированный HTML-код в файл, который вы просто читаете и выводите, если кеш не является недействительным. Другой вариант - сериализация объектов PHP в файлы. Прочтите о различных методах кэширования для вашей платформы (я предполагаю, PHP?)
Используйте другое решение для резервного копирования. Если вы используете только таблицы MyISAM, загляните в mysqlhotcopy. Обычно проблемы с таблицами MyISAM возникают из-за полной блокировки таблиц при резервном копировании.
Сделать резервную копию из подчиненной базы данных, находящейся на другой машине, но ваш провайдер говорит вам, что они не могут этого сделать? Мне кажется некомпетентным.