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, и от этого они стали сильно медленнее.