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. Шеберді бірдей бумамен жаңартыңыз.

Жоспардың әрбір нүктесін қарастырайық және ненің дұрыс болмауы мүмкін екенін көрейік.

МАҢЫЗДЫ! Galera негізіндегі MySQL кластерін жаңарту процедурасының мақалада сипатталмаған өзіндік нәзіктіктері бар. Бұл жағдайда сіз бұл нұсқаулықты пайдаланбауыңыз керек.

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.

Тексеру үшін біз Percona серверінің Docker кескінін қолданамыз. Біз сервер конфигурациясын каталогқа орналастырамыз 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-қабығы (Перкона жағдайында бұл пакет 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

Міне, біз алған пікірлер:

Жалпы алғанда, маңызды ештеңе жоқ - тек кодтау туралы ескертулер (төменде қараңыз). Жалпы орындау нәтижесі:

Жаңарту еш қиындықсыз өтуі керек деп шештік.

Кодтау ақауларын көрсететін жоғарыдағы ескертулер туралы ескертпе. Өйткені, соңғы уақытқа дейін MySQL-де UTF-8 UTF-8 «шын» емес еді, өйткені ол 3 емес, тек 4 байтты сақтады. MySQL 8-де бұл мүмкін. түзетуге шешім қабылдады: бүркеншік ат utf8 жақын арада кодтауға әкеледі utf8mb4, және кестелердегі ескі бағандар болады utf8mb3. Әрі қарай кодтау utf8mb3 жойылады, бірақ бұл шығарылымда емес. Сондықтан, біз оны жаңартқаннан кейін іске қосылған ДҚБЖ орнатуындағы кодтауларды түзетуді шештік.

3-бөлім: Сервер жаңартулары

Осындай ақылды жоспар болған кезде не істен шығуы мүмкін?.. Нюанстар әрқашан болатынын жақсы түсініп, біз MySQL әзірлеуші ​​кластерінде бірінші эксперимент жүргіздік.

Жоғарыда айтылғандай, ресми құжаттама репликалармен MySQL серверлерін жаңарту мәселесін қамтиды. Ең алдымен, барлық көшірмелерді (құлдар) жаңарту керек, өйткені 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 және т. Егер сіздің дерекқорыңыз бастапқыда 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 сценарийі.

Неліктен бізде әзірлеушіде мұндай проблемалар болмады? Деректер базасы мезгіл-мезгіл өндірістен көшіріледі - осылайша, кестелер қайта жасалады.

Өкінішке орай, шынымен жұмыс істейтін үлкен дерекқорда сіз әмбебапты алып, орындай алмайсыз. 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 демонының операциялық жүйеден қажетті ресурстарды ала алмайтынын анықтады. Қателерді сұрыптау кезінде біз жүйеде анықтадық "жетім" аппармор саясат файлдары:

# 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 нұсқасына бірнеше жыл бұрын жаңарту кезінде жасалған және жойылған пакетке жатады. Файлдарды жою және аппармор қызметін қайта іске қосу мәселені шешті:

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 кеңестері мен амалдары: үлкен дерекқорлар үшін жүктеуді жылдамдату«;
• «Біздің SRE күнделікті өмірімізден 6 практикалық әңгіме«;
• «K8s ішіндегі Redis операторымен бір оқиға және осы дерекқордағы деректерді талдауға арналған утилиталарға шағын шолу«;
• «MongoDB-тің Kubernetes-ке үздіксіз көшуі«.

Ақпарат көзі: www.habr.com