MySQL -прокси и показать время запроса ProcessList

Question

У меня есть репликация MySQL, в настоящее время происходит между двумя мастерами двунаправленной, одной в центре обработки данных локально, другой на Amazon EC2.

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

Что мы заметили недавно, так это то, что MySQL Proxy уведомит нас, что есть 41 соединение, а затем начнет балансировать. Однако, когда я подключаюсь к локальной машине и делаю SHOW PROCESSLIST; Это может дать мне только 30 соединений.

У кого -нибудь есть идеи, почему это может быть?

В дополнение к этому в результате выдачи SHOW PROCESSLIST; Команда Я заметил, что на обеих машинах используется очень много запросов, в которых говорится, что они работают свыше 5000 секунд. Я почти уверен, что это «зомби», но кто -нибудь знает, почему они созданы в первую очередь?

К вашему сведению, мы запускаем MySQL версии 5.1.54 в последних версиях Ubuntu и Debian.

Любые идеи были бы чрезвычайно полезными.

Приложение

Оказывается, мы не используем mysql_pconnect и на самом деле используем библиотеки Mysqli. Я до сих пор не смог выяснить, почему это происходит, и я сообщу, как я узнаю.

Answer 1

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

Сотни подключений «сна» практически не влияют на сервер, поэтому ограничение до 40 не полезно. 10 или более активный Соединения (не спят) могут быть проблемой. В этом случае я бы посмотрел на запросы. Обычно оптимизация запросов - лучший ответ.

Также обратите внимание, что каждая запись (вставка, обновление и т. Д.), Которая сделанная на одном мастере, должна быть сделана для всех других мастеров и рабов. Итак, вы не можете «распространяться», пишет.

Если у вас есть процессы, которые выполняют только чтения (выбирают), то они должны перейти к рабам и/или резервному мастеру, а не к живой, записей, который можно записать, мастер. Это поможет.

Помните о проблеме «критической записи». Пример: пользователь публикует комментарий в блоге, затем смотрит на его комментарии, но он отсутствует. Это может произойти, если запись перенесена на одну машину, но чтение ударило другую, а репликация «позади».

(Мои комментарии применяются ко всем версиям, и на все API, а не только 5.1 и Php's Mysqli.)

Я держусь подальше от mysql_pconnect (и других механизмов объединения). Запуск/разрыв подключения очень быстро в MySQL. Объединенные соединения могут иметь проблемы с @Variables, режимами транзакций, SQL_Modes и т. Д.