Как я могу использовать 2 сервера баз данных для моего сайта?

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

• Оптимизировать настройки MySQL - Существуют десятки параметров конфигурации, которые могут сильно повлиять на производительность MySQL. Убедитесь, что вы изучили этот вариант, прежде чем решить, действительно ли вам нужно масштабировать.
• Оптимизировать приложение - Как сказал Пол, убедитесь, что ваше приложение работает разумно. Если вы не используете правильные индексы и запросы, у вас будет плохая производительность, независимо от количества серверов, и в конечном итоге вы будете тратить деньги / время.
• Увеличение масштаба - Получение большей машины может быть более простым решением в зависимости от того, на каком уровне оборудования вы сейчас используете. Однако для каждого приложения есть момент, когда будет дешевле / лучше начать масштабирование (репликация / сегментирование).
• Репликация - Обычная конфигурация - один главный сервер и несколько подчиненных серверов. Мастер получает все запросы на запись, и любое из подчиненных устройств может обслуживать запросы на чтение. Это хорошо для случаев, когда вы ожидаете намного больше операций чтения, чем записи.
• Шардинг - Наличие нескольких серверов MySQL, каждый из которых обрабатывает часть общей базы данных. Например, пользователи a-d находятся на db1, e-i на db2 и т. Д. Я считаю, что это обрабатывается на уровне приложения, а не в самом MySQL.

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

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

Проанализируйте слайды одного из ребят из livejournal здесь: http://www.danga.com/words/2004_mysqlcon/

Я предлагаю начать оптимизацию ваших запросов и ваших индексов. Это снизило мою нагрузку в среднем с 4 до 0,5. Потрясающе, да? Добавляя только дополнительные индексы.

HTH

Кластер их.

Обычно вы хотите, чтобы все ваши записывать операции всегда идут к одному и тому же (ведущему), и вы используете какую-то форму репликации для синхронизации новых данных от ведущего к ведомым. Затем вы можете использовать балансировщик нагрузки для распределения запросов чтения между различными доступными физическими серверами, понимая, что для некоторых вещей эти серверы могут быть немного устаревшими. Балансировщик нагрузки также должен быть достаточно умен, чтобы знать, что определенные виды запросов должны выполняться с главного сервера, так что, например, когда я добавляю этот пост в Stack Overflow, мне не нужно ждать репликации, чтобы догнать, чтобы увидеть мой новый пост, если я закончу балансировку нагрузки на вторичный сервер. Короче говоря, приложение должно быть написано, чтобы знать об этом. Вы не можете просто включить параметр в базе данных и заставить все работать.

Суть, вероятно, будет лучше, если вы просто обновите сервер. Запуск двух действующих баз данных значительно усложняет работу и не оправдывает сравнительно небольших затрат на оборудование. Действительно большие системы используют такие вещи, как Oracle RAC, для запуска одной и той же базы данных на нескольких машинах, но это еще не похоже на вашу зону кластера серверов за миллион долларов. Наличие горячего резервирования - всегда хорошая идея, и вы можете использовать репликацию, чтобы держать его наготове.

1. Вы можете разделить чтение и запись SQL на уровне приложения. Настройте репликацию с двумя серверами, которые у вас есть в приложении (я предполагаю, что вы используете класс для обработки чтения, записи, подключения к серверу БД) везде, где у вас есть запись, удаление, замена, обновление SQL, чтобы они подключились к вашему главному серверу и все, что вы читаете, SQL подключаются к подчиненному серверу. Таким образом, вы можете снять нагрузку с вашего главного сервера.
2. Применяя структуру репликации, вам также необходимо оптимизировать ваши таблицы (индекс, ..) и ваши запросы, чтобы получить максимальную производительность. Также не забудьте настроить параметры репликации и контролировать трафик серверов, и если вы видите, что поступает больше SQL-запросов для чтения, чем для записи, тогда в будущем вы можете добавить второй подчиненный сервер к своему архитектору.
3. Если вы используете решение для репликации, не забывайте, что ваша подчиненная версия MySQL должна быть той же версии, что и главная, или выше, иначе репликация в какой-то момент сломается.
4. Репликация - это хорошая и распространенная структура, но с этим также возникают проблемы. Например, если репликация прерывается, вы должны знать, как запустить подчиненное устройство с точки разрыва, чтобы оба сервера были синхронизированы друг с другом.
5. Если бы это был я, я бы сначала попытался оптимизировать свои SQL-запросы, запросы и таблицы, контролировать свой трафик и посмотреть, есть ли у меня больше запросов на чтение или запись, и на основе этого я бы сделал шаг вложенности.