• UAH
  • USD
  • RUB
  • EUR
  • +38(044) 392-74-33  Киев
  • +38(057) 728-39-00  Харьков
  • +38(056) 794-38-31  Днепропетровск
  • +38(062) 210-24-93  Донецк
  • +38(032) 229-58-93  Львов
  • +38(048) 738-57-70  Одесса
  • +38(093) 449-04-21  Life
  • +38(067) 400-88-44  Киевстар
  • +38(095) 007-72-35  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 15:46
хостинг: есть
домен: есть
Хотелось бы иметь возможность видеть лог подключений к 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 16:13
хостинг: есть
домен: есть
Хотелось бы иметь возможность видеть что в этот момент происходит на стороне MySQL сервера. © admin263

В данный момент реализовать такую схему довольно проблематично, так как включение general_log на MYSQL сервере требует перезагрузки и генерирует колоссальный объем информации, который поступает от всех пользователей.
admin263
21.07.2017 17:00
хостинг: есть
домен: есть
Ну лог по всем транзакциям и не нужен, а только по событиям внешних подключений объем будет небольшой. Есть же у вас лог по подключениям по ftp и логи по Apache.
Евгений В.
21.07.2017 17:20
хостинг: есть
домен: нет
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 18:03
хостинг: есть
домен: есть
У нас три сайта интернет-магазина, три 1С которые выгружают товары и читают заказы, причем задания по чтению и записи разные, каждое открывает свое соединение. Каким образом мы можем проконтролировать, что мы не делаем более 10 соединений в минуту? Были бы логи внешних подключений, мы бы это увидели.
С другой стороны, раз вы каким-то образом считаете эти 10 соединений в минуту, то какие то логи все-таки есть?
Ну и с третьей стороны откуда взялась цифра 10 внешних соединений в минуту на максимальном тарифном плане где почти все неограничено?
Илья
21.07.2017 21:13
хостинг: есть
домен: есть
Каким образом мы можем проконтролировать, что мы не делаем более 10 соединений в минуту? © admin263

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

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

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

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

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

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

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


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

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

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

Тема закрыта по истечению срока давности.
Горячая линия
(044)
392 74 33
другие города