Актуализиране на 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. Актуализирайте подчинените бази данни чрез инсталиране на пакета percona-server-server.
4. Актуализирайте главния файл със същия пакет.

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

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

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

MySQL беше премахнат във версия 8 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-сървър:

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 [Warning] [MY-011068] [Server] The syntax 'expire-logs-days' is deprecated and will be removed in a future release. Please use binlog_expire_logs_seconds instead.
2020-04-03T12:44:19.671678Z 0 [Warning] [MY-013242] [Server] --character-set-server: 'utf8' is currently an alias for the character set UTF8MB3, but will be an alias for UTF8MB4 in a future release. Please consider using UTF8MB4 in order to be unambiguous.
2020-04-03T12:44:19.671682Z 0 [Warning] [MY-013244] [Server] --collation-server: 'utf8_general_ci' is a collation of the deprecated character set UTF8MB3. Please consider using UTF8MB4 with an appropriate collation instead.

По този начин все още трябваше да разберем кодировките и да заменим остарялата директива 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: Сървърни актуализации

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

Както вече споменахме, официална документация обхваща въпроса за актуализиране на MySQL сървъри с реплики. Изводът е, че първо трябва да актуализирате всички реплики (slave), тъй като MySQL 8 може да репликира от главна версия 5.7. Известна трудност се крие във факта, че използваме режима майстор <-> майстор, когато дистанционното управление е в режим само за четене. Тоест всъщност бойният трафик отива към един център за данни, а вторият е резервен.

Топологията изглежда така:

Актуализацията трябва да започне с реплики mysql реплика 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 и вижте, че таблиците с броячи в базата данни на приложението са актуализирани.

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

Нямаше тъга - актуализирахме продукта

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

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

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-сървърът използва различен начин за съхраняването им. Ако вашата база данни първоначално беше във версия 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 ще помогне тук: помощната програма pt-online-schema-change е отлична за онлайн операцията OPTIMIZE.

Актуализираният план изглеждаше така:

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 за техните отлични продукти!

PS

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

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

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