Uppdaterar MySQL (Percona Server) från 5.7 till 8.0

Framstegen står aldrig stilla, så anledningarna att uppgradera till de senaste MySQL-versionerna blir alltmer övertygande. Nyligen behövde ett av våra projekt uppgradera sina mysiga Percona Server 5.7-kluster till version 8. Allt detta gjordes på plattformen. Ubuntu Linux 16.04 april. Hur man utför den här åtgärden med minimal driftstopp och vilka problem vi stötte på under uppdateringen – läs den här artikeln.

Utbildning

Varje uppdatering av databasservern är troligtvis förknippad med omkonfiguration av databasen: ändringar i krav på systemresursgränser och korrigering av databaskonfigurationer, vilka måste rensas från föråldrade direktiv.

Innan vi uppdaterar kommer vi definitivt att hänvisa till den officiella dokumentationen:

• Versionsinformation för MySQL 8;
• MySQL-uppdateringsguide;
• Percona Uppgraderingsguide;
• MySQL-guide för att uppgradera repliker och masters.

Och låt oss göra en handlingsplan:

1. Åtgärda konfigurationsfiler genom att ta bort föråldrade direktiv.
2. Kontrollera kompatibilitet med verktyg.
3. Uppdatera slavdatabaser genom att installera paketet percona-server-server.
4. Uppdatera mastern genom att installera samma paket.

Låt oss titta på varje punkt i planen och se vad som kan gå fel.

VIKTIGT! Proceduren för att uppdatera ett MySQL-kluster baserat på Galera har sina egna finesser, vilka inte beskrivs i artikeln. Du bör inte använda den här instruktionen i ett sådant fall.

Del 1: Kontrollera konfigurationer

I den åttonde versionen av MySQL togs den bort query_cacheEgentligen var han det. förklarad föråldrad tillbaka i version 5.7, men nu borttagen heltFöljaktligen är det nödvändigt att ta bort de relaterade direktiven. Och för cachning av frågor kan du nu använda externa verktyg - till exempel, ProxySQL.

Även i konfigurationen fanns det föråldrade direktiv om innodb_file_formatOm MySQL 5.7 hade möjlighet att välja InnoDB-formatet, så fungerar version 8 redan. endast med Barracuda-format.

Vårt resultat är att följande direktiv tas bort:

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

För att kontrollera använder vi Percona Server Docker-avbildningen. Vi placerar serverkonfigurationen i katalogen mysql_config_test, och bredvid den skapar vi kataloger för data och loggar. Exempel på percona-serverkonfigurationstest:

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

Resultatet: antingen i Docker-loggarna eller i logs-katalogen – beroende på dina konfigurationer – kommer en fil att visas som beskriver de problematiska direktiven.

Detta är vad vi hade:

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.

Så vi var fortfarande tvungna att lista ut kodningarna och ersätta det föråldrade direktivet. expire-logs-days.

Del 2: Kontroll av fungerande installationer

Uppdateringsdokumentationen innehåller två verktyg för att kontrollera databasens kompatibilitet. Genom att använda dem kan administratören kontrollera kompatibiliteten hos den befintliga datastrukturen.

Låt oss börja med det klassiska mysqlcheck-verktyget. Kör det bara:

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

Om inga problem hittas avslutas verktyget med kod 0:

Dessutom har moderna versioner av MySQL ett verktyg tillgängligt. mysql-skal (i Perconas fall är det ett paket) percona-mysql-shell). Den ersätter den klassiska mysql-klienten och kombinerar funktionerna hos en klient, en SQL-kodredigerare och MySQL-administrationsverktyg. För att kontrollera servern innan du uppdaterar kan du köra följande kommandon genom den:

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

Och här är kommentarerna vi fick:

I allmänhet inget kritiskt - bara varningar om kodningar (se nedan). Totalt resultat av utförandet:

Vi bestämde att uppdateringen skulle gå utan problem.

En anmärkning om varningarna ovan som indikerar kodningsproblem. Saken är den att UTF-8 i MySQL fram tills nyligen var inte "riktig" UTF-8, eftersom den bara lagrade 3 byte istället för 4. I MySQL 8 är detta äntligen bestämde mig för att fixa det: alias utf8 kommer snart att leda till kodning utf8mb4, och de gamla kolumnerna i tabellerna kommer att bli utf8mb3Vidare kodning utf8mb3 kommer att tas bort, men inte i den här versionen. Därför beslutade vi att åtgärda kodningarna som redan finns på den pågående DBMS-installationen, efter dess uppdatering.

Del 3: Uppdatera servrar

Vad kan gå fel när det finns en så briljant plan?... Väl medvetna om att nyanser alltid uppstår, genomförde vi det första experimentet på ett MySQL-utvecklingskluster.

Som redan nämnts, officiell dokumentation behandlar frågan om att uppdatera MySQL-servrar med repliker. Kärnan är att du bör uppdatera alla repliker (slave) först, eftersom MySQL 8 kan replikera från masterversion 5.7. En viss svårighet ligger i det faktum att vi använder läget mästare <-> mästare, när fjärrstyrningsmastern är i läge skrivDet vill säga att stridstrafiken faktiskt kommer till ett datacenter, och det andra är en backup.

Topologin ser ut så här:

Uppdateringen bör börja med repliker mysql-replika dc 2, mysql master dc 2 и mysql replica dc 1och avsluta med mysql master dc 1-servern. För ökad tillförlitlighet stoppade vi de virtuella maskinerna, tog ögonblicksbilder av dem och omedelbart före uppdateringen stoppade vi replikeringen med kommandot STOP SLAVEAnnars ser uppdateringen ut så här:

1. Vi startar om varje replik och lägger till 3 alternativ i konfigurationerna: skip-networking, skip-slave-start, skip-log-binPoängen är att uppdatering av databasen genererar binära loggar med uppdatering av systemtabellerna. Dessa direktiv garanterar att applikationsdata inte ändras i databasen, och information om uppdatering av systemtabellerna kommer inte att hamna i binärloggarna. Detta kommer att undvika problem när replikeringen återupptas.
2. Installera paketet percona-server-serverDet är viktigt att notera att i MySQL version 8 ingen behöver köra kommandot mysqlupgrade efter serveruppdatering.
3. Efter en lyckad start, starta om servern igen – den här gången utan de parametrar som lades till i den första punkten.
4. Se till att replikeringen fungerar korrekt: kontrollera SHOW SLAVE STATUS och vi ser att tabellerna med räknare i applikationsdatabasen uppdateras.

Allt detta ser enkelt ut: utvecklaruppdateringen lyckades. Okej, vi kan tryggt schemalägga den nattliga uppdateringen för produktion.

Det fanns ingen sorg - vi uppdaterade prod.

Att överföra framgångsrik utvecklingserfarenhet till produktion var dock inte utan överraskningar.

Lyckligtvis börjar själva uppdateringsprocessen med repliker, så när vi stötte på problem stoppade vi arbetet och återställde repliken från en ögonblicksbild. Undersökningen av problemen sköts upp till nästa morgon. Följande poster hittades i loggarna:

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

En studie av arkiven för olika e-postlistor i Google ledde till förståelsen att detta problem uppstår pga. MySQL-buggÄven om det mer troligt är en bugg i verktygen mysqlcheck и mysqlsh.

Det visar sig att MySQL har ändrat hur den presenterar data för decimalfält (int, tinyint, etc.), så mysql-server använder ett annat sätt att lagra dem internt. Om din databas initialt var i version 5.5 eller 5.1, och sedan uppdaterade du till 5.7, då kan du behöva utföra OPTIMIZE för vissa tabeller. Sedan uppdaterar MySQL datafilerna och överför dem till det aktuella lagringsformatet.

Du kan också kontrollera detta med verktyget 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',
...

Om field_type Om du har 0, använder tabellen den gamla typen - du måste utföra OPTIMIZEMen om värdet är 246 har du redan en ny typ. Du kan läsa mer om typerna i koda.

Dessutom i den här buggen Den andra möjliga anledningen som vi inte har beaktat är avsaknaden av InnoDB-tabeller i systemtabellen. INNODB_SYS_TABLESPACES, om de, tabellerna, skapades i version 5.1. För att undvika problem vid uppdatering kan du använda med det bifogade SQL-skriptet.

Varför hade vi inte sådana problem på utvecklarsidan? Databasen kopieras regelbundet dit från produktionssidan - alltså, tabellerna återskapas.

Tyvärr kommer det inte vara möjligt att helt enkelt ta och utföra en allestädes närvarande enkät på en stor och verklig databas. OPTIMIZEPercona-toolkit hjälper till här: verktyget pt-online-schema-change är perfekt för OPTIMIZE-operationen online.

Den uppdaterade planen blev så här:

1. Optimera alla tabeller.
2. Utför en databasuppdatering.

För att testa det och även ta reda på uppdateringstiden inaktiverade vi en av replikerna och körde följande kommando för alla tabeller:

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

Uppdatering av tabeller sker utan långa låsningar eftersom verktyget skapar en ny temporär tabell, till vilken det kopierar data från huvudtabellen. När båda tabellerna är identiska blockeras den ursprungliga tabellen och ersätts av den nya. I vårt fall visade en testkörning att uppdatering av alla tabeller skulle ta ungefär en dag, men kopiering av data orsakade för mycket belastning på diskarna.

För att undvika detta lade vi till ett argument till kommandot i produktionsläge. --sleep Med värdet 10 reglerar denna parameter väntetiden efter överföring av en databatch till en ny tabell. Detta kan minska belastningen om den faktiska applikationen som körs är krävande vad gäller svarstid.

Efter att optimeringen hade utförts lyckades uppdateringen.

... men inte helt och hållet!

Redan en halvtimme efter uppdateringen kom klienten med ett problem. Databasen fungerade mycket konstigt: periodvis anslutningsåterställningarSå här såg det ut i övervakningen:

Skärmdumpen visar ett sågtandsdiagram, vilket är relaterat till det faktum att några av MySQL-servertrådarna regelbundet kraschade med ett fel. Applikationen började få fel:

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

En snabb granskning av loggarna visade att mysqld-daemonen inte kunde hämta de nödvändiga resurserna från operativsystemet. När vi felsökte felen hittade vi följande i systemet: "föräldralösa" apparmor-policyfiler:

# 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

Dessa filer skapades under en uppgradering till MySQL 5.7 för ett par år sedan och tillhör ett borttaget paket. Att ta bort filerna och starta om apparmor-tjänsten löste problemet:

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

Sammanfattningsvis

Varje operation, även den enklaste, kan leda till oväntade problem. Och inte ens en väl genomtänkt plan garanterar alltid det förväntade resultatet. Nu inkluderar alla uppdateringsplaner från vårt team också obligatorisk rensning av onödiga filer som kan ha uppstått till följd av de senaste åtgärderna.

Och med detta inte så professionella grafiska skapande vill jag rikta ett stort tack till Percona för deras utmärkta produkter!

PS

Läs även på vår blogg:

• «Databaser och Kubernetes (översikt och videorapport)";
• «Kubernetes tips och tricks: snabba upp bootstrap av stora databaser";
• «6 praktiska berättelser från vår SRE-vardag";
• «En historia med Redis-operatören i K8s och en minigranskning av verktyg för att analysera data från denna databas";
• «Sömlös migrering av MongoDB till Kubernetes".

Källa: will.com