четверг, 2 сентября 2021 г.

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

Android после IOS

        Немного холивара на тему IOS vs Android. Мой первый смартфон был на Android - HTC Magic, это был вообще второй в мире телефон на Андроид. Потом я на долго перешел на IOs (лет на 8). И тут недавно решил снова перейти на Android (так как 90% наших клиентов используют Android). Купил я себе POCO Max 3 Pro. Первые 2 недели была конечно боль - перелом шаблонов и тд. Но об этом много написано, не буду повторяться. Хочу отметить только одну вещь - после 2 месяцев на Android я взял в руки старый iPhone и понял простую вещь - даже у старого iPhone интерфейс очень быстрый. Быстрее чем у Android. Шторка с уведомлениями, все остальное - сильно быстрее работает. Когда ты постоянно с этим работаешь - ты этого не замечаешь. Но привыкнув к Android, ты понимаешь что iPhone сильно быстрее работает.