• UAH
  • USD
  • RUB
  • EUR
  • +38(044) 392-74-33  Киев
  • +38(057) 728-39-00  Харьков
  • +38(056) 794-38-31  Днепр
  • +38(032) 229-58-93  Львов
  • +38(048) 738-57-70  Одесса
  • +38(093) 170-15-42  Life
  • +38(067) 400-88-44  Киевстар
  • +38(095) 630-90-82  MTC
  • +1(888)393-24-51  USA, Toll free
  • +44(131)507-01-14  Great Britain
  • +7(499) 348-28-61  Москва

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

Форумы Пожелания и предложения Хотелось бы иметь возможность видеть лог подключений к MySQL серверу
admin263
21.07.2017
хостинг: есть
домен: есть
Хотелось бы иметь возможность видеть лог подключений к 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 сервера.
Илья
21.07.2017
хостинг: есть
домен: есть
Хотелось бы иметь возможность видеть что в этот момент происходит на стороне MySQL сервера. © admin263

В данный момент реализовать такую схему довольно проблематично, так как включение general_log на MYSQL сервере требует перезагрузки и генерирует колоссальный объем информации, который поступает от всех пользователей.
admin263
21.07.2017
хостинг: есть
домен: есть
Ну лог по всем транзакциям и не нужен, а только по событиям внешних подключений объем будет небольшой. Есть же у вас лог по подключениям по ftp и логи по Apache.
Евгений В.
21.07.2017
хостинг: есть
домен: нет
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) © admin263

В данной ситуации имеет смысл проверить, не создается ли к xxx.mysql.ukraine.com.ua в процессе синхронизации более 10 соединений в минуту?
Так как при превышении этого лимита для соединений извне (не с серверов хостинга) все последующие (до снижения частоты попыток ниже лимита в 10 подкл/мин) будут блокироваться, что и приведет к ошибке Can't connect to MySQL server.
admin263
21.07.2017
хостинг: есть
домен: есть
У нас три сайта интернет-магазина, три 1С которые выгружают товары и читают заказы, причем задания по чтению и записи разные, каждое открывает свое соединение. Каким образом мы можем проконтролировать, что мы не делаем более 10 соединений в минуту? Были бы логи внешних подключений, мы бы это увидели.
С другой стороны, раз вы каким-то образом считаете эти 10 соединений в минуту, то какие то логи все-таки есть?
Ну и с третьей стороны откуда взялась цифра 10 внешних соединений в минуту на максимальном тарифном плане где почти все неограничено?
Илья
21.07.2017
хостинг: есть
домен: есть
Каким образом мы можем проконтролировать, что мы не делаем более 10 соединений в минуту? © admin263

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

С другой стороны, раз вы каким-то образом считаете эти 10 соединений в минуту, то какие то логи все-таки есть? © admin263

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

Ну и с третьей стороны откуда взялась цифра 10 внешних соединений в минуту на максимальном тарифном плане где почти все неограничено? © admin263

Максимальный тарифный план - это отдельный сервер, на котором будет только ваш сайт. Находясь на виртуальном хостинге ресурсы делятся между множеством сайтов и хостинг провайдер является арбитром, который следит за тем, что б не было злоупотреблений. У нас есть отдельные сервера, на которые мы переносим сайты пользователей, которые хотят безлимит, но когда они чуствуют на собственном сайте к чему приводит то, что пользователи ничем не ограничены и просто убивают сервер, то они просят перенести сайт обратно так как там просто ничего не работает, хотя и пользователей там на порядок меньше чем на сервере с ограничениями. Относительно юридической составляющей: п. 11 в 5 разделе. Условия предоставления услуг
admin263
25.07.2017
хостинг: есть
домен: есть
Попробуем использовать connection pool со своей стороны.
Тем не менее, не совсем понятно почему внешние подключения к базам данных вы рассматриваете только для обслуживания баз. Нагрузка на хостинг увеличится, если сайт сам будет запрашивать данные у 1С и писать их себе в базу для обновления каталога интернет магазина. Вы считаете такой подход более правильным?
Илья
25.07.2017
хостинг: есть
домен: есть
2
Это правило было добавлено благодаря слаженным действиям ряда пользователей, которые приводили к тому, что остальным пользователям не оставалось ресурсов. Добавили мы это правило и ряд нарушений исчезло, уменьшилось количество жалоб на неработоспособность MySQL. Ведь мало кто задумывается насколько его действия приведут к ухудшению качества работы хостинга для других клиентов. Вот взять к примеру ваш случай - проблема решается, если не закачивать данные одновременно большим количеством потоков, а выполняя их по очереди. Одну базу обновили, вторую, третью. Можно все это на одном подключении организовать. И ограничение остается и нагрузка не создается и проблем другим пользователям нет.
admin263
25.07.2017
хостинг: есть
домен: есть
Илья, мне понятно, что основная ваша забота в том, что бы всем было хорошо (хватало ресурсов). Но я как пользователь должен понимать на какие ресурсы я могу рассчитывать. По этому, все ограничения должны быть четко описаны.
Вот взять к примеру наш случай - мы ловили ошибки синхронизации очень долгое время, пока не увеличили нагрузку и проблема стала более явной. А она решилась бы быстрее, если бы мы изначально знали об ограничениях. А может этой проблемы вообще бы не было, написали бы алгоритм по-другому и не пришлось бы теперь платить за переписывание синхронизации 1С.
И никто из пользователей не должен задумываться насколько его действия приведут к ухудшению качества работы хостинга. Это исключительно Ваша задача - используя разумные ограничения обеспечивать стабильность работы и максимальное количество ресурсов для каждого пользователя.

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

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


Это не правильно. Как по Вашему я должен учитывать потребности других абонентов?! Такие формулировки как прикрытие, дающее возможность вводить ограничения без изменения основного договора. © admin263

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

Если вы уже зарегистрированы Вам необходимо войти на форум.

Горячая линия
(044)
392 74 33
другие города