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

При синхронизации сайта интернет-магазина с 1С возникают периодически ошибки ODBC драйвера
Error calling context method (Open): An exception has occurred (Microsoft OLE DB Provider for ODBC Drivers): [MySQL][ODBC 5.1 Driver]Can't connect to MySQL server on 'xxx.mysql.ukraine.com.ua' (10054)
Хотелось бы иметь возможность видеть что в этот момент происходит на стороне MySQL сервера.

В данный момент реализовать такую схему довольно проблематично, так как включение general_log на MYSQL сервере требует перезагрузки и генерирует колоссальный объем информации, который поступает от всех пользователей.

Ну лог по всем транзакциям и не нужен, а только по событиям внешних подключений объем будет небольшой. Есть же у вас лог по подключениям по ftp и логи по Apache.

В данной ситуации имеет смысл проверить, не создается ли к xxx.mysql.ukraine.com.ua в процессе синхронизации более 10 соединений в минуту?
Так как при превышении этого лимита для соединений извне (не с серверов хостинга) все последующие (до снижения частоты попыток ниже лимита в 10 подкл/мин) будут блокироваться, что и приведет к ошибке Can't connect to MySQL server.

У нас три сайта интернет-магазина, три 1С которые выгружают товары и читают заказы, причем задания по чтению и записи разные, каждое открывает свое соединение. Каким образом мы можем проконтролировать, что мы не делаем более 10 соединений в минуту? Были бы логи внешних подключений, мы бы это увидели.
С другой стороны, раз вы каким-то образом считаете эти 10 соединений в минуту, то какие то логи все-таки есть?
Ну и с третьей стороны откуда взялась цифра 10 внешних соединений в минуту на максимальном тарифном плане где почти все неограничено?

Необходимо выполнять запрос SHOW FULL PROCESSLIST в отдельном подключении и тогда сможете увидеть количество одновременных подключений.


Это делается на Firewall.


Максимальный тарифный план - это отдельный сервер, на котором будет только ваш сайт. Находясь на виртуальном хостинге ресурсы делятся между множеством сайтов и хостинг провайдер является арбитром, который следит за тем, что б не было злоупотреблений. У нас есть отдельные сервера, на которые мы переносим сайты пользователей, которые хотят безлимит, но когда они чуствуют на собственном сайте к чему приводит то, что пользователи ничем не ограничены и просто убивают сервер, то они просят перенести сайт обратно так как там просто ничего не работает, хотя и пользователей там на порядок меньше чем на сервере с ограничениями. Относительно юридической составляющей: п. 11 в 5 разделе. Условия предоставления услуг

Попробуем использовать connection pool со своей стороны.
Тем не менее, не совсем понятно почему внешние подключения к базам данных вы рассматриваете только для обслуживания баз. Нагрузка на хостинг увеличится, если сайт сам будет запрашивать данные у 1С и писать их себе в базу для обновления каталога интернет магазина. Вы считаете такой подход более правильным?

Это правило было добавлено благодаря слаженным действиям ряда пользователей, которые приводили к тому, что остальным пользователям не оставалось ресурсов. Добавили мы это правило и ряд нарушений исчезло, уменьшилось количество жалоб на неработоспособность MySQL. Ведь мало кто задумывается насколько его действия приведут к ухудшению качества работы хостинга для других клиентов. Вот взять к примеру ваш случай - проблема решается, если не закачивать данные одновременно большим количеством потоков, а выполняя их по очереди. Одну базу обновили, вторую, третью. Можно все это на одном подключении организовать. И ограничение остается и нагрузка не создается и проблем другим пользователям нет.

Илья, мне понятно, что основная ваша забота в том, что бы всем было хорошо (хватало ресурсов). Но я как пользователь должен понимать на какие ресурсы я могу рассчитывать. По этому, все ограничения должны быть четко описаны.
Вот взять к примеру наш случай - мы ловили ошибки синхронизации очень долгое время, пока не увеличили нагрузку и проблема стала более явной. А она решилась бы быстрее, если бы мы изначально знали об ограничениях. А может этой проблемы вообще бы не было, написали бы алгоритм по-другому и не пришлось бы теперь платить за переписывание синхронизации 1С.
И никто из пользователей не должен задумываться насколько его действия приведут к ухудшению качества работы хостинга. Это исключительно Ваша задача - используя разумные ограничения обеспечивать стабильность работы и максимальное количество ресурсов для каждого пользователя.

Вы в соседней теме пишите выдержку из новой редакции договора "Проте ресурси серверів і інтернет каналів не бувають безмежними, тому Виконавець вимагає , щоб Абоненти використовували ресурси Виконавця з урахуванням того, що в них потребують і інші Абоненти, які повинні на рівних правах використовувати їх. "
Это не правильно. Как по Вашему я должен учитывать потребности других абонентов?! Такие формулировки как прикрытие, дающее возможность вводить ограничения без изменения основного договора.

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



Не всегда отсутствие четких ограничений это плохо:
1. Мы не блокируем почту клиентов, даже если они превышают квоту. Почта должна всегда приходить и тут лучше когда нет четкого ограничения. Но с другой стороны у нас появились клиенты у которых почтовые ящики по 2Тб (не 2 Гб, а 2 000 Гб). Какое ограничение поставить в таком случае?
2. Обращения в техподдержку - есть клиент, который считает, что он может получить все знания техподдержки и пишет 200 обращений в месяц. Опять таки поставить ограничение для всех пользователей - неправильно.
IMHO нужно блокировать тот 1% пользователей, которые злоупотребляют, а не наказывать всех жесткими лимитами.

Илья, спасибо, что прислушиваетесь.
Ваше желание дать больше, чем ожидают Ваши пользователи, заслуживает уважения.
Это наверное приятно, когда превысив квоту продолжаешь получать почту. (Хотя нам до превышения очень далеко)
А вот с диском, дойдя до 200000 inode мы уперлись жестко. Хотя места было еще полно. Пока не уперлись и не знали, что это такое inode.
За счет размытых границ пользователи получают сюрпризы, иногда приятные, иногда нет.