Актуализация на MySQL (Percona Server) от 5.7 до 8.0

Напредъкът не спира, така че причините да актуализираме до новите версии на MySQL стават все по-важни. Неотдавна в един от нашите проекти дойде времето да обновим приятните клъстери на Percona Server 5.7 до версия 8. Всичко това се случва на платформата Ubuntu Linux 16.04. Как да извършите подобна операция с минимален престой и с какви проблеми се сблъскахме при актуализацията - прочетете в тази статия.

Подготовка

Всяко обновление на сървъра на база данни вероятно е свързано с повторна конфигурация на базата: промени в изискванията за лимити на системни ресурси и корекции в конфигурационните файлове, които трябва да се освободят от остарели директиви.

Преди обновлението непременно ще се обърнем към официалната документация:

• Бележки за изданието на MySQL 8;
• Ръководство за обновление от MySQL;
• Ръководство за обновление от Percona;
• Ръководство на MySQL за обновление на реплики и майстори.

И ще съставим план за действие:

1. Коригирайте конфигурационните файлове, като премахнете остарелите директиви.
2. Проверете съвместимостта с утилитите.
3. Актуализирайте slave-базите, като инсталирате пакета percona-server-server.
4. Актуализирайте майстора, избирайки същия пакет.

Нека разгледаме всяка точка от плана и да видим какво би могло да се обърка.

ВАЖНО! Процедурата за обновление на MySQL-клъстера на базата на Galera има своите нюанси, които не са описани в статията. Не бива да използвате тази инструкция в такъв случай.

Част 1: Проверка на конфигурациите

В 8-а версия на MySQL е премахнат query_cache. Всъщност той бе признат за остарял още в версия 5.7, но сега е напълно премахнат. Съответно, необходимо е да премахнем свързаните директиви. А за кеширане на заявки сега можете да използвате външни инструменти — например, ProxySQL.

Също така в конфигурацията намерихме остарели директиви за innodb_file_format. Ако в MySQL 5.7 имаше възможност за избор на формат на InnoDB, то 8-а версия вече работи само с формата Barracuda.

Нашият извод — премахване на следните директиви:

• query_cache_type, query_cache_limit и query_cache_size;
• innodb_file_format и innodb_file_format_max.

За проверка ще използваме Docker изображение на Percona Server. Конфигурацията на сървъра ще поставим в директория mysql_config_test, а до нея ще създадем директории за данни и логове. Пример за тест на конфигурацията на percona-server:

mkdir -p {mysql_config_test,mysql_data,mysql_logs}
cp -r /etc/mysql/conf.d/* mysql_config_test/
docker run  --name some-percona -v $(pwd)/mysql_config_test:/etc/my.cnf.d/  -v $(pwd)/mysql_data/:/var/lib/mysql/ -v $(pwd)/mysql_logs/:/var/log/mysql/ -e MYSQL_ROOT_PASSWORD=${MYSQL_PASSWORD} -d percona:8-centos

В заключение: в логах Docker или в директории с логами - в зависимости от ваших конфигураций - будет создан файл, в котором будут описаны проблемные директивы.

Вот что у нас было:

2020-04-03T12:44:19.670831Z 0 [Предупреждение] [MY-011068] [Сервер] Синтаксис 'expire-logs-days' устарел и будет удален в будущих версиях. Пожалуйста, используйте binlog_expire_logs_seconds вместо.
2020-04-03T12:44:19.671678Z 0 [Предупреждение] [MY-013242] [Сервер] --character-set-server: 'utf8' в настоящее время является псевдонимом для набора символов UTF8MB3, но в будущем будет псевдонимом для UTF8MB4. Пожалуйста, рассмотрите возможность использования UTF8MB4 для большей однозначности.
2020-04-03T12:44:19.671682Z 0 [Предупреждение] [MY-013244] [Сервер] --collation-server: 'utf8_general_ci' является сводом устаревшего набора символов UTF8MB3. Пожалуйста, рассмотрите возможность использования UTF8MB4 с соответствующим сводом вместо этого.

Таким образом, нам нужно было понять кодировки и заменить устаревшую директиву expire-logs-days.

Часть 2: Проверка работающих установок

В документации по обновлению есть 2 утилиты для проверки базы на совместимость. Их использование помогает администратору проверить совместимость текущей структуры данных.

Начнем с классической утилиты mysqlcheck. Просто выполните команду:

mysqlcheck -u root -p --all-databases --check-upgrade

Если проблемы не обнаружены, утилита завершится кодом 0:

Кроме того, в современных версиях MySQL доступна утилита mysql-shell (в случае Percona это пакет percona-mysql-shell). Она является заменой классическому клиенту mysql и сочетает в себе функции клиента, редактора SQL-кода и инструменты администрирования MySQL. Для проверки сервера перед обновлением через нее вы можете выполнить следующую команду:

mysqlsh -- util check-for-server-upgrade { --user=root --host=1.1.1.1 --port=3306 } --config-path=/etc/mysql/my.cnf

И вот какие замечания мы получили:

В общем, ничего критичного — только предупреждения о кодировках (вж. по-долу). Общий результат выполнения:

Мы решили, что обновление должно пройти без проблем.

Замечание о предупреждениях выше, свидетельствующих о проблемах с кодировками. Дело в том, что UTF-8 в MySQL до недавнего времени не была «настоящей» UTF-8, так как хранила только 3 байта вместо 4. В MySQL 8 это наконец-то было исправлено: алиас utf8 вскоре будет соответствовать кодировке utf8mb4, а старые столбцы в таблицах станут utf8mb3. В дальнейшем эта кодировка utf8mb3 будет удалена, но не в данном релизе. Поэтому мы решили исправить кодировки уже на работающей инсталляции СУБД, после ее обновления.

Часть 3: Обновление серверов

Какво може да се обърка, когато имаме толкова чудесен план?.. Разбирайки, че нюансите винаги се случват, първият експеримент проведохме на dev кластера MySQL.

Както вече споменахме, официалната документация осветлява въпроса за обновяването на MySQL сървъри с реплики. Същността е, че първо трябва да обновим всички реплики (slave), тъй като MySQL 8 може да репликира от майстор с версия 5.7. Някои трудности произтичат от факта, че използваме режим master master, когато отдалечен майстор е в режим read-only. Тоест фактически работният трафик постъпва в един ЦОД, а вторият е резервен.

Топологията изглежда по следния начин:

Обновлението трябва да започне с репликите mysql replica dc 2, mysql master dc 2 и mysql replica dc 1, а да завърши с сървъра mysql master dc 1. За по-голяма надеждност спряхме виртуалните машини, направихме им снимки, а непосредствено преди обновлението спряхме репликацията с командата STOP SLAVE. В противен случай обновлението изглежда така:

1. Рестартираме всяка реплика, добавяйки в конфигурациите 3 опции: skip-networking, skip-slave-start, skip-log-bin. Факт е, че обновлението на базата генерира бинарни логове с обновление на системните таблици. Тези директиви гарантират, че в базата няма да се променят данни от приложението, а в бинарните логове няма да попадне информация за обновление на системните таблици. Това ще предотврати проблеми при възобновяване на репликацията.
2. Инсталираме пакета percona-server-server. Важно е да се отбележи, че в версия MySQL 8 не трябва да стартирате командата mysqlupgrade след обновлението на сървъра.
3. След успешен старт, отново рестартираме сървъра — вече без параметрите, които бяха добавени в първата стъпка.
4. Убедете се, че репликацията работи успешно: проверете SHOW SLAVE STATUS и вижте, че таблиците с броячи в базата на приложението се обновяват.

Всичко това изглежда достатъчно просто: обновлението на dev премина успешно. Добре, можем спокойно да планираме нощното обновление за продукция.

Не беше зле — prod обновявахме

Но пренасянето на успешния опит от dev към продукция не мина без изненади.

За щастие, самият процес на обновление започва с репликите, затова, срещайки трудности, спряхме работата и възстановихме репликата от снимката. Проучването на проблемите прехвърлихме за следващата сутрин. В логовете се оказаха следните записи:

2020-01-14T21:43:21.500563Z 2 [ERROR] [MY-012069] [InnoDB] table: t1 has 19 columns but InnoDB dictionary has 20 columns
2020-01-14T21:43:21.500722Z 2 [ERROR] [MY-010767] [Server] Error in fixing SE data for db1.t1
2020-01-14T21:43:24.208365Z 0 [ERROR] [MY-010022] [Server] Failed to Populate DD tables.
2020-01-14T21:43:24.208658Z 0 [ERROR] [MY-010119] [Server] Aborting

Изследването на архивите на различни имейл разпространения в Google доведе до разбирането, че такава проблема възниква заради бъг в MySQL. Всъщност, това е повече бъг в инструментите mysqlcheck и mysqlsh.

Оказва се, че в MySQL е променен начинът на представяне на данните за десетични полета (int, tinyint и т.н.), затова вътре в mysql-server се използва друг начин на съхранение. Ако вашата база данни първоначално е била в версия 5.5 или 5.1 и след това сте актуализирали до 5.7, може да е необходимо да извършите OPTIMIZE за някои таблици. Тогава MySQL ще актуализира файловете с данни, превеждайки ги на актуален формат на съхранение.

Също така, това може да се провери с инструмента mysqlfrm:

mysqlfrm --diagnostic -vv /var/lib/mysql/db/table.frm
...
 'field_length': 8,
  'field_type': 246, # формат на полето
  'field_type_name': 'decimal',
  'flags': 3,
  'flags_extra': 67,
  'interval_nr': 0,
 'name': 'you_deciaml_column',
...

Ако field_type ако е равно на 0, то в таблицата се използва стар тип — трябва да се извърши OPTIMIZE. Но ако стойността е 246 — имате нов тип. Подробности за типовете можете да намерите в код.

Освен това, в този бъг се разглежда втора възможна причина, която ни е подминала — това е липсата на InnoDB таблици в системната таблица INNODB_SYS_TABLESPACES, ако те, таблиците, са били създавани в версия 5.1. За да се избегнат проблеми при актуализация, можете да използвате приложения SQL скрипт.

Защо не се появиха такива проблеми на dev? Базата веднъж на известно време се копира от продукция — по този начин, таблиците се пресъздават.

За съжаление, на реална работеща голяма БД не може просто да вземете и да изпълните всестранно OPTIMIZE. Тук ще помогне percona-toolkit: за операция онлайн OPTIMIZE много добре подхожда инструментът pt-online-schema-change.

Актуализираният план стана следния:

1. Да се оптимизира всички таблици.
2. Да се актуализират базите данни.

За да го проверим и заедно да установим време за актуализация, изключихме един от репликите и за всички таблици стартирахме следната команда:

pt-online-schema-change --critical-load Threads_running=150 --alter "ENGINE=InnoDB" --execute --chunk-size 100 --quiet --alter-foreign-keys-method auto h=127.0.0.1,u=root,p=${MYSQL_PASSWORD},D=db1,t=t1

Актуализация на таблиците се извършва без дълги блокировки, благодарение на факта, че инструментът създава нова временна таблица, в която копира данните от основната таблица. В момента, когато и двете таблици са идентични, основната таблица се заключва и се заменя с новата. В нашия случай тестовият старт показа, че за обновление на всички таблици ще е необходим около ден, но в същото време копирането на данни предизвикваше твърде голямо натоварване на дисковете.

За да избегнем това, на продукция добавихме към командата аргумент --sleep с значение 10 — този параметър регулира продължителността на изчакването след преместването на пакет данни в новата таблица. Така можем да намалим натоварването, ако реално стартираното приложение е взискателно към времето за отговор.

След извършване на оптимизацията, обновлението премина успешно.

… но не напълно!

Вече след половин час след обновлението клиентът дойде с проблем. Базата работеше много странно: периодично започваха сброси на свързвания. Ето как изглеждаше това в мониторинга:

На скрийншота се вижда зъбчат график, свързан с това, че част от потоковете на MySQL сървъра периодично падали с грешка. В приложението се появиха грешки:

[PDOException] SQLSTATE[HY000] [2002] Connection refused

Бърз преглед на логовете показа, че демонът mysqld не можа да получи необходимите ресурси от операционната система. Разбирайки грешките, открихме в системата „безстопанствени“ файлове на политиките на apparmor:

# dpkg -S /etc/apparmor.d/cache/usr.sbin.mysqld
dpkg-query: no path found matching pattern /etc/apparmor.d/cache/usr.sbin.mysqld
# dpkg -S /etc/apparmor.d/local/usr.sbin.mysqld
dpkg-query: no path found matching pattern /etc/apparmor.d/local/usr.sbin.mysqld
# dpkg -S /etc/apparmor.d/usr.sbin.mysqld
mysql-server-5.7: /etc/apparmor.d/usr.sbin.mysqld
# dpkg -l mysql-server-5.7
rc  mysql-server-5.7 5.7.23-0ubuntu0.16.04.1      amd64

Тези файлове са възникнали при ъпгрейда до MySQL 5.7 преди няколко години и принадлежат на изтрит пакет. Изтриването на файловете и рестартиране на услугата apparmor реши проблема:

systemctl stop apparmor
rm /etc/apparmor.d/cache/usr.sbin.mysqld
rm /etc/apparmor.d/local/usr.sbin.mysqld
rm /etc/apparmor.d/usr.sbin.mysqld
systemctl start apparmor

В заключение

Всяка, дори най-простата операция, може да доведе до непредвидени проблеми. И дори наличието на обмислен план не винаги гарантира очаквания резултат. Сега във всеки план за обновление нашият екип включва и задължителното почистване на излишни файлове, които биха могли да се появят в резултат на последните действия.

А с това не твърде професионално графично творчество бих искал да благодаря на компанията Percona за техните отлични продукти!

P.S.

Прочетете също в нашия блог:

• «Бази данни и Kubernetes (преглед и видео на доклада)»;
• «Kubernetes съвети и трикове: ускоряване на bootstrap на големи бази данни»;
• «6 практични истории от нашата SRE действителност»;
• «Една история с оператора Redis в K8s и мини-преглед на инструментите за анализ на данни от тази база данни»;
• «Безпроблемна миграция на MongoDB в Kubernetes».

Източник: habr.com