MySQL8

       Не так давно мы мигрировали с MySQL 5.7 на MySQL 8 (Percona Server 8 если быть точным). Из того что заслуживает внимания: пришлось подчистить конфиги от директив конфигурации которые были удалены. Если их не убрать то сервер не запустится. 

    Второе - пришлось повозится с open_files_limit, innodb_open_files, table_open_cache и max_connections. MySQL сервер стал настолько умный что начал проверять системные лимиты, и если выставленные значения open_files_limit больше разрешенных системой - он их автоматически уменьшает. 

      innodb_open_files не может быть больше open_files_limit. Это в принципе логично, но сейчас сервер это проверяет и если это не так - ругается. 

      Также сервер проверяет table_open_cache, которое также зависит от максимального количества файлов которые mysqld может держать открытым. Сюда же добавляется зависимость от max_connections - так как открытые сокеты это те же файловые дескрипторы. MySQL8 использует следующую формулу для подсчета необходимых файловых дескрипторов - 10 + max_connections + (table_open_cache * 2) https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_open_files_limit Если результат меньше, то сервер автоматически уменьшает значение table_open_cache до table_open_cache=(open_files_limit- (max_connections + 10))/2 или дефолтного минимума (400), если рассчитанное по формуле значение меньше дефолтного.

     В общем у нас системные лимиты не соответствовали значениям конфигов и table_open_cache переменная сбросилась на дефолтные значения(400). В результате MySQL внезапно стал тормозить после апгрейда.  Самое плохое что select @@table_open_cache; показывает тебе не правильное значение (то что установлено в конфигах, а не то что на самом деле). Только строчка в error лог указывает на это: 

2021-09-03T09:48:05.447570Z 0 [Warning] [MY-010140] [Server] Could not increase number of max_open_files to more than 65536 (request: 140010)

2021-09-03T09:48:05.447577Z 0 [Warning] [MY-010142] [Server] Changed limits: table_open_cache: 27763 (requested 65000)

         Еще одной проблемой стало обновление кодировок - в MySQL8 появилась полноценная utf8 - utf8mb4. Она же стала дефолтной кодировкой. Поэтому для избежания путаницы пришлось все переводить на utf8mb4. 

        Вообще в MySQL8 была проделана огромная работа по выпиливанию старого говна/legacy кода. Куча всего что было deprecated, наконец-то было официально выпилено. Некоторые части кода переписали на использования C++ std библиотеки. Пофиксили множество редко встречающихся, но довольно болезненных багов - все что связано с не атомарностью/консистентностью  изменений в структуре таблиц, авто инкрементов и тд. В результате некоторые вещи стали сильно медленнее. Например information_schema. Теперь все таблицы information_schema это table views, и от этого они стали сильно медленнее. 

Бага в PHP PDO Mysql

      Наткнулся  на замечательную багу в PHP PDO Mysql - после обновления PHP c 5.3.1 до 5.3.2  последний rowset в пакетном SQL запросе просто перестал возвращатся. В общем случае возможность выполнять несколько SQL запросов за одно соединение не часто используется - в основном в силу сложности аггрегирования несвязных запросов в один пакет. Но в моем случае mysql соединение использовалось для выполнения запросов к Sphinx. А в sphinxQL к примеру для того чтобы получить общее количество документов удовлетворяющих критерию - без учета выражения LIMIT необходимо отправлять сразу два запроса в одном пакете - непосредственно запрос по выборке документов и "SHOW META". Также если вы отправляете несколько схожих запросов одним пакетом - то сфинкс может их оптимизировать, кэшируя общие поддеревья. В общем пока придется дописывать в каждый пакет дополнительный запрос "SHOW META" чтобы как-то обходить это ограничение - другого решения этой проблемы я пока не знаю.

Дамп таблиц по LIKE

mysql $DB -u$USERNAME -p$PASSWORD -e 'show tables like "$LIKE%"' | grep -v Tables_in | xargs mysqldump --add-drop-table $DB -u$USERNAME -p$PASSWORD

Golang and MySQL

Просмотрев все имеющиеся на данный момент реализации MySQL клиентов для Go пришел к выводу что самая работоспособная из них - mymysql (https://github.com/ziutek/mymysql)
Остальные давно не развиваются и по видимому заброшены разработчиками.

Хозяйке на заметку

Несколько полезных ссылок - напочитать.
http://dtrace.org/blogs/brendan/ - много полезного про исследования производительности систем
http://www.cyberciti.biz/tips/top-linux-monitoring-tools.html - шпаргалка по базовым утилитам
http://www.markleith.co.uk/ очень полезный блог по MySQL оптимизации
http://www.percona.tv/mysql-conference/using-mysql-5-5-performance-schema использование perfomance schema в MySQL

openark kit

Вчера открыл для себя openark kit - набор утилит для работы с MySQL. В отличии от своего старшего брата - Percona Toolkit написаны на python. Функциональность этих двух пакетов конечно пересекается, но есть и кое какие уникальные инструменты. В общем надо будет как-нибуть их опробовать в условиях, приближенных к боевым.

HandlerSocket

Наткнулся на очень интересную презентацию по HandlerSocket:

Ускоряем MySQL в десятки раз с использованием HandlerSocket

View more PowerPoint from Alexandre Kalendarev

Самое интересное в конце: модуль для NGINX для обращения к HandlerSocket через AJAX.

Интересная альтернатива Percona + HandlerSocket

Наткнулся на очень интересный эксперимент -  товарищи из финской комнапии Innobase решили скрестить ужа с ежом и не получить при этом метр колючей проволоки. Если быть конкретнее - они предложии использовать Memcached протокол для обращения напрямую к InnoDB плагину MySQL сервера.
Детали тут: http://blogs.innodb.com/wp/2011/04/nosql-to-innodb-with-memcached/
Выглядит как отличная альтернатива Percona+HandlerSocket
Правда у HandlerSocket есть одно преимущество - через него можно работать с любыми storage engine, а не только с InnoDB