Спасибо за обратную связь и приношу извинения за потраченное время. Действительно статья была написана давно, много изменений было и основной функционал сейчас стал платным. Мы внесем корректировки в эту статью.
Скачивать каждый раз необходимости особой нет, но планировали чтобы он был актуальный. Информацию принял и завел issue на эту тему. Мы обсудим и дадим обратную связь.
Да, работы по новым версиям ведутся, но медленно. Много проделали работы по улучшению качества конфигурационных файлов MySQL для старых версий.
Инженеры подтвердили, если пароль для MySQL вводится вручную, то этот пароль MySQLTuner сохраняет в отчете JSON в разделе «MySQL Client». В случае если используется файл с данными для подключения пароль не сохраняется и не передается.
Информацию из этого раздела мы не используем для обработки и исторического анализа метрик, поэтому сейчас готовим обновление для исключения сбора этой информации и удаления ее в ранее собранных отчетах.
Спасибо, что выделили время, протестировали в рабочем окружении и дали подробную обратную связь.
Проект молодой и больше позиционируем его, как первый шаг на пути оптимизации MySQL, поэтому пока он не может заменить полностью ручной процесс оптимизации.
Все замечания обсудим с командой и добавим соответствующие Issue.
Уточните, пожалуйста, во сколько по времени Вы делали запрос к сервису для более детального анализа? (можно в личку)
Пока не понятно по какой причине, но в Вашем случае при запуске MySQLTuner была установлена опция skipsize, в результате в отчет не попала информация о размерах данных в используемых механизмах хранения MySQL. Уточните, пожалуйста, Вы редактировали скрипт или запускали как есть?
Проблему увидели.
В данном случае формат данных отчета MySQLTuner для percona отличается от тех на которых мы проводили тестирование (MySQL 5.5, 5.6 и 5.7).
Создал issue по этой проблеме. Я отпишусь тут по решению.
Спасибо, что дали обратную связь. Сейчас такое поведение в основном связано с тем, что:
1. мы пока не поддерживаем MySQL версии 8.
2. MySQLTuner не смог собрать корректный отчет. (в основном из-за того что прав не достаточно)
Проверили запросы поступающие на сервис, но за последнее время не увидели ошибочных. Уточните, пожалуйста, когда и во сколько примерно делали запрос к сервису?
Спасибо за обратную связь и приношу извинения за потраченное время. Действительно статья была написана давно, много изменений было и основной функционал сейчас стал платным. Мы внесем корректировки в эту статью.
Да, работы по новым версиям ведутся, но медленно. Много проделали работы по улучшению качества конфигурационных файлов MySQL для старых версий.
Задача по поддержки более новых версий и MySQL 8 пока ещё в работе.
Текущие поддерживаемые версии:
Инженеры подтвердили, если пароль для MySQL вводится вручную, то этот пароль MySQLTuner сохраняет в отчете JSON в разделе «MySQL Client». В случае если используется файл с данными для подключения пароль не сохраняется и не передается.
Информацию из этого раздела мы не используем для обработки и исторического анализа метрик, поэтому сейчас готовим обновление для исключения сбора этой информации и удаления ее в ранее собранных отчетах.
Проект молодой и больше позиционируем его, как первый шаг на пути оптимизации MySQL, поэтому пока он не может заменить полностью ручной процесс оптимизации.
Все замечания обсудим с командой и добавим соответствующие Issue.
Уточните, пожалуйста, во сколько по времени Вы делали запрос к сервису для более детального анализа? (можно в личку)
Похоже мы уперлись в лимиты облака Amazon для сервиса Lambda — 6Mb на запрос. Видно, что запрос приходит, но до сервиса не доходит.
Можно ли у Вас попросить полный файл отчета MySQLTuner в личку и мы передадим Вам подготовленный сервисом конфигурационный файл?
В данном случае формат данных отчета MySQLTuner для percona отличается от тех на которых мы проводили тестирование (MySQL 5.5, 5.6 и 5.7).
Создал issue по этой проблеме. Я отпишусь тут по решению.
1. мы пока не поддерживаем MySQL версии 8.
2. MySQLTuner не смог собрать корректный отчет. (в основном из-за того что прав не достаточно)
Проверили запросы поступающие на сервис, но за последнее время не увидели ошибочных. Уточните, пожалуйста, когда и во сколько примерно делали запрос к сервису?