MySQL кластер с балансировкой нагрузки без балансировки нагрузки

Я пытаюсь создать кластер MySQL с балансировкой нагрузки, но без фактического балансировщика нагрузки, чтобы не добавить еще одну точку отказа или сложности.

Я думал о том, чтобы иметь следующее:

1. Есть мастер-мастер настройки для MySQL

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

Это возможно? Или есть лучшие способы добиться этого?

Пожалуйста, прочтите мой другой ответ на этот вопрос, прежде чем использовать прокси MySQL любого типа. Если у вас есть 2 сервера master-master, на которые пишет CMS, и 10 httpd, которые только читают с него, у вас все будет хорошо, но (как указано в другом ответе) это не всегда так. Вы были предупреждены.

MySQL Proxy - это простая программа, которая находится между вашим клиентом и сервером (ами) MySQL, которая может контролировать, анализировать или преобразовывать их связь. Его гибкость позволяет неограниченное использование; общие включают в себя: распределение нагрузки; отказоустойчивого; анализ запросов; фильтрация и модификация запросов; и многое другое.

,

HAProxy - это бесплатное, очень быстрое и надежное решение, обеспечивающее высокую доступность, балансировку нагрузки и прокси для приложений на базе TCP и HTTP.

Если вы запустите его в режиме TCP, он может быть даже лучше, чем Wackamole. Если бы мне пришлось выбирать между ними, я бы использовал HAProxy. Также HAProxy может иметь много бэкэндов, Waclamole может иметь только 2. Обратите внимание, что HAProxy «тупой», он соединяет сокеты, не глядя на то, что находится внутри потока - выделенный MySQL Proxy может иметь возможность направлять различные запросы на указанные серверы. ,

Вероятно, стоит упомянуть, Galera Replication for MySQL для истинной установки с несколькими мастерами MySQL. Galera - это протокол синхронной репликации, поэтому приложения могут читать и записывать на любой из серверов MySQL. Вот краткое руководство: http://www.severalnines.com/clustercontrol-mysql-galera-tutorial

Что касается балансировщиков нагрузки перед серверами MySQL, используйте либо коннектор MySQL, который поддерживает эту функцию (например, Connector / J для Java или Mysqlnd для php)

Если у вас нет соединителя, который может это сделать, используйте что-то вроде HA Proxy. Этот скрипт автоматически устанавливает HA Proxy и поддерживает список хороших серверов MySQL: https://github.com/severalnines/haproxy

С наилучшими пожеланиями,

Виней

www.severalnines.com

Репликация мастер-мастер не так хороша, как вы могли бы подумать, то же самое относится и к циклическому прокси и аналогичным «простым» решениям. Если вы передаете конфликтующие данные на отдельные серверы достаточно быстро (быстрее, чем задержка между серверами, которая на рабочих серверах может составлять до полной секунды *), оба примут данные. Если у вас есть сервер аукциона, вы продали один и тот же автомобиль дважды . Кто купил это? Это зависит от того, какую БД Вы спросите!

Приложение должно знать, что на самом деле существует 2 базы данных, и оно должно знать оба их IP-адреса. Если Вы хотите «продать», Вам следует

DB_number = `auction_number` % `number_of_databases`

( %для modulo)

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

Кроме того, IP-адреса должны быть wackamole -d между обоими серверами. В случае аварии, когда один сервер базы данных отключается в течение нескольких часов в пиковое время использования, вы обнаружите, что приложение будет пытаться подключиться к отсутствующему серверу и зависать, пока время не истечет, скажем, 3 с. Внезапно половина ваших запросов выполняется на 3 секунды дольше (и все они в конечном итоге попадают в одну и ту же базу данных, что не позволяет выполнять ее быстрее, чем до катастрофы). Это не делает Ваш httpd счастливым, так как он, вероятно, имеет ограниченный пул соединений с параллельными потоками обработчика запросов ...

* Задержка репликации на производственных серверах может составлять до полной секунды - я проверил это в удаленном расположении и в нашем центре обработки данных и примерно в 99% случаев это 0, но иногда mysql показывает 1 с. При большом трафике у меня было много коллизий из-за того, что клиентское приложение делало два запроса, в результате чего два запроса вставлялись и выбирались. В некоторых случаях строки просто еще не было , поэтому мы использовали хэш userID, и это устранило проблему

Я надеюсь, что Вы будете учиться на моих ошибках ;-)

Кластер базы данных MySQL с балансировкой нагрузки (или какой-то другой) довольно бесполезен. Если вы пишете более чем на один сервер, вы столкнетесь с проблемами или будете использовать синхронную репликацию (которую MySQL не поддерживает в любом случае), и это сильно снижает производительность, поскольку требует синхронизации блокировок.

Я рекомендую вам разделить нагрузки чтения / записи и сбалансировать нагрузку для чтения среди подчиненных MySQL, и иметь либо один мастер для записи, либо использовать активную / пассивную пару отработки отказа для своего мастера.

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

Чтобы масштабировать записи, вам необходимо логически разделить данные между несколькими серверами, разделив их на части или «разделив» и т. Д. Это обычно требует нетривиальных (кажется, очень сложных для тестирования) изменений в вашем приложении, поэтому вы не захотите делать это, пока вы НАСТОЯЩИМ нужно это.

Конечно, вы можете использовать кластер MySQL, если вы действительно этого хотите, но это совершенно другой движок с его собственными функциями и недостатками - его немного сложно настроить, но он действительно обеспечивает базу данных с балансировкой нагрузки HA на аппаратном оборудовании. Он по-прежнему страдает от снижения производительности записи из-за использования синхронной репликации, но позволяет масштабировать записи, поскольку он встроен в разделение между серверами.

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

http://www.dancryer.com/2010/01/mysql-circular-replication

Это первая часть из трех статей серии:

• MySQL Load-Balanced Cluster Guide - часть 1 - настройка самих серверов и настройка репликации MySQL.

• MySQL Load-Balanced Cluster Guide - часть 2 - настройте скрипт для мониторинга состояния ваших узлов кластера MySQL, который мы будем использовать в следующем руководстве для настройки нашего прокси.

• MySQL Load-Balanced Cluster Guide - Часть 3 - Настройка балансировки нагрузки с HAProxy с использованием скриптов мониторинга

Лично лучше бы использовать балансировщик нагрузки!

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

Connector / J имеет возможность распределять запросы между несколькими серверами. Это в первую очередь предназначено для MySQL NDB Cluster, где все узлы SQL будут иметь согласованное представление данных, но если вы сможете гарантировать, что база данных двух мастеров будет разумно согласована между этими двумя мастерами, это может быть безопасно для вашего приложения.

Строка подключения будет выглядеть примерно так:

jdbc: mysql: loadbalance: // host-1, host-2, ... host-n / dbname? loadBalanceStrategy = "random" & loadBalanceBlacklistTimeout = 5000

Разделение записей не снимает нагрузку с серверов, потому что записи все еще должны быть реплицированы.

Если вы используете только 2 сервера, используйте heartbeat с drbd и позвольте drbd обрабатывать репликацию. Если первый сервер выходит из строя, второй сервер вступает во владение. Если вы хотите использовать второй сервер, вы можете использовать gfs поверх drbd, а затем запустить второй сервер только для чтения и использовать его в качестве сервера чтения. Когда происходит аварийное переключение, измените сервер на чтение / запись.

Re: Wackamole - Wackamole не ограничивается 2 сервера

Я работаю над серией учебных пособий, посвященных этому, но ее очень просто настроить.

Чтобы дать более свежий ответ на этот вопрос, в версии 5.6 MySQL он представил GTID (Global Transaction Identifieres), цель которого сделать асинхронную репликацию более надежной и снова поставить MySQL в гонку за HA (высокая доступность).

В этом разделе описана репликация на основе транзакций с использованием глобальных идентификаторов транзакций (GTID). При использовании GTID каждая транзакция может быть идентифицирована и отслежена, поскольку она зафиксирована на исходном сервере и применена любыми подчиненными устройствами; это означает, что при использовании идентификаторов GTID нет необходимости ссылаться на файлы журналов или позиции в этих файлах при запуске нового ведомого устройства или переключении на новый ведущий, что значительно упрощает эти задачи. Поскольку репликация на основе GTID полностью основана на транзакциях, легко определить, являются ли ведущие и ведомые устройства согласованными; до тех пор, пока все транзакции, совершенные на главном устройстве, также совершаются на ведомом устройстве, согласованность между ними гарантируется. Вы можете использовать репликацию на основе операторов или строк с GTID (см. Раздел 16.2.1, «Форматы репликации»); Однако для достижения наилучших результатов

Ссылка: 16.1.3 Репликация с глобальными идентификаторами транзакций (документация MySQL)

Я подумал, что использование HAProxy для балансировки запросов вводит SPOF (единую точку отказа), и добавление тактового импульса делает это решение громоздким.

Более простое решение - подключиться через Java-коннектор JConnector, который предназначен для загрузки запросов балансировки через URL-адрес jdbc со всеми узлами MySQL. Он может работать с настройками ведущий / ведомый или ведущий / ведущий .

Это позволяет настраивать кластерное решение HA из коробки с MySQL.