🥇Aggiornamentu di MySQL (Server Percona) da 5.7 à 8.0

U prugressu ùn si ferma mai, dunque e ragioni per passà à l'ultime versioni di MySQL diventanu sempre più convincenti. Recentemente, unu di i nostri prughjetti avia bisognu di aghjurnà i so accoglienti cluster Percona Server 5.7 à a versione 8. Tuttu què hè statu fattu nantu à a piattaforma. Ubuntu Linux 16.04 d'aprile. Cumu fà sta operazione cù un tempu di inattività minimu è chì prublemi avemu scontru durante l'aghjurnamentu - leghjite questu articulu.

A preparazione di

Qualchese aghjurnamentu di u servitore di basa di dati hè più prubabilmente assuciatu cù a ricunfigurazione di a basa di dati: cambiamenti in i requisiti per i limiti di i risorse di u sistema è a correzione di e cunfigurazioni di basa di dati chì deve esse sbulicatu da direttive obsolete.

Prima di l'aghjurnà, faremu di sicuru riferite à a documentazione ufficiale:

È scrivimu un pianu d'azzione:

Corrige i fugliali di cunfigurazione rimuovendu direttive obsolete.
Verificate a cumpatibilità cù l'utilità.
Aghjurnate e basa di dati slave installendu u pacchettu percona-server-server.
Aghjurnate u maestru cù u listessu pacchettu.

Fighjemu ogni puntu di u pianu è vede ciò chì puderia sbaglià.

IMPORTANTE! A prucedura per aghjurnà un cluster MySQL basatu nantu à Galera hà e so suttilità chì ùn sò micca descritte in l'articulu. Ùn avete micca aduprà sta struzzione in questu casu.

Parte 1: Verificazione di e cunfigurazioni

MySQL hè statu eliminatu in a versione 8 query_cache. In verità era dichjarata obsoleta torna in a versione 5.7, ma avà sguassatu cumplettamente. Per quessa, hè necessariu di sguassà e direttive assuciate. È per cache e dumande pudete avà aduprà strumenti esterni - per esempiu, ProxySQL.

Ancu in a cunfigurazione ci eranu direttive obsolete circa innodb_file_format. Se in MySQL 5.7 era pussibule di selezziunà u formatu InnoDB, allora a versione 8th funziona digià solu cù u furmatu Barracuda.

U nostru risultatu hè a rimuzione di e seguenti direttive:

query_cache_type, query_cache_limit и query_cache_size;
innodb_file_format и innodb_file_format_max.

Per verificà, avemu aduprà l'imaghjini Docker di Percona Server. Puderemu a cunfigurazione di u servitore in u cartulare mysql_config_test, è vicinu à questu avemu da creà cartulari per dati è logs. Esempiu di prova di cunfigurazione 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

Bottom line: sia in i logs di Docker, sia in u cartulare cù i logs - secondu a vostra cunfigurazione - appariscerà un schedariu in quale seranu descritte e direttive problematiche.

Eccu ciò chì avemu avutu:

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.

Cusì, avemu sempre bisognu di scopre e codificazioni è rimpiazzà a direttiva obsoleta expire-logs-days.

Parte 2: Verificazione di l'installazione di travagliu

A documentazione di l'aghjurnamentu cuntene 2 utilità per verificà a basa di dati per a compatibilità. U so usu aiuta l'amministratore à verificà a cumpatibilità di a struttura di dati esistenti.

Cuminciamu cù l'utilità classica mysqlcheck. Simply run:

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

Se ùn ci sò micca prublemi, l'utilità escerà cù u codice 0:

Inoltre, una utilità hè dispunibule in versioni muderni di MySQL mysql-shell (in u casu di Percona questu hè u pacchettu percona-mysql-shell). Hè un sustitutu per u cliente mysql classicu è combina e funzioni di un cliente, un editore di codice SQL è strumenti di amministrazione MySQL. Per verificà u servitore prima di aghjurnà, pudete eseguisce i seguenti cumandamenti attraversu:

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

Eccu i cumenti chì avemu ricevutu:

In generale, nunda di criticu - solu avvisi nantu à e codificazioni (vede sottu). Risultato generale di l'esecuzione:

Avemu decisu chì l'aghjurnamentu deve andà senza prublemi.

Una nota nantu à l'avvirtimenti sopra chì indicanu prublemi cù codificazioni. U fattu hè chì UTF-8 in MySQL finu à pocu tempu ùn era micca "veru" UTF-8, postu chì hà guardatu solu 3 bytes invece di 4. In MySQL 8 questu hè infine decisu di riparà: alias utf8 prestu porta à a codificazione utf8mb4, è i vechji culonni in i tavule diventeranu utf8mb3. Ulteriore codificazione utf8mb3 serà eliminatu, ma micca in questa liberazione. Dunque, avemu decisu di curregà i codificazioni digià nantu à a stallazione DBMS in esecuzione, dopu avè aghjurnatu.

Parte 3: Actualizazioni di u Server

Chì puderia esse sbagliatu quandu ci hè un pianu cusì intelligente? .. Cumprendu bè chì i sfumaturi sempre succedenu, avemu realizatu u primu esperimentu nantu à un cluster dev MySQL.

Cum'è digià citatu, documentazione ufficiale copre u prublema di l'aghjurnamentu di i servitori MySQL cù rèpliche. U fondu hè chì duvete prima aghjurnà tutte e repliche (slaves), postu chì MySQL 8 pò riplicà da una versione maestra 5.7. Certi difficultà si trova in u fattu chì avemu aduprà u modu maestru <-> maestru, quandu u maestru remoto hè in modu solu di lettura. Questu hè, in fattu, u trafficu di cummattimentu va à un centru di dati, è u sicondu hè una copia di salvezza.

A topologia s'assumiglia cusì:

L'aghjurnamentu deve principià cù repliche replica mysql dc 2, mysql master dc 2 и mysql replica dc 1, è finiscinu cù u servitore mysql master dc 1 Per esse più affidabile, avemu firmatu i machini virtuali, hà pigliatu snapshots di elli, è immediatamente prima di l'aghjurnamentu fermatu a replicazione cù u cumandimu. STOP SLAVE. U restu di l'aghjurnamentu s'assumiglia cusì:

Ripartemu ogni replica aghjunghjendu 3 opzioni à e cunfigurazioni: skip-networking, skip-slave-start, skip-log-bin. U fattu hè chì l'aghjurnamentu di a basa di dati genera logs binari cù l'aghjurnamenti à e tavule di u sistema. Queste direttive guarantisci chì ùn ci saranu micca cambiamenti à i dati di l'applicazioni in a basa di dati, è l'infurmazioni nantu à l'aghjurnamentu di e tavule di u sistema ùn saranu micca inclusi in i logs binari. Questu eviterà prublemi quandu ripiglià a replicazione.
Stallà u pacchettu percona-server-server. Hè impurtante à nutà chì in MySQL versione 8 ùn avete bisognu di eseguisce u cumandamentu mysqlupgrade dopu l'aghjurnamentu di u servitore.
Dopu un principiu successu, riavvia u servitore di novu - senza i paràmetri chì sò stati aghjuntu in u primu paràgrafu.
Avemu assicuratu chì a replicazione funziona bè: verificate SHOW SLAVE STATUS è vede chì i tavule cù cuntatori in a basa di dati di l'applicazione sò aghjurnati.

Tuttu pare abbastanza simplice: l'aghjurnamentu di u dev hè successu. Ok, pudete pianificà in modu sicuru un aghjurnamentu di notte per a produzzione.

Ùn ci era micca tristezza - avemu aghjurnatu u prod

Tuttavia, u trasferimentu di l'experientia di dev successu à a pruduzzione ùn hè micca senza sorprese.

Fortunatamente, u prucessu di l'aghjurnamentu stessu principia cù rèpliche, cusì quandu avemu scontru difficultà, avemu firmatu u travagliu è restauratu a replica da a snapshot. L'investigazione di i prublemi hè stata posposta finu à a matina dopu. I logs cuntenenu e seguenti entrate:

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

A ricerca di l'archivi di diverse listi di mailing in Google hà purtatu à capisce chì stu prublema si trova per via Bug MySQL. Ancu s'ellu hè più prubabilmente un bug di utilità mysqlcheck и mysqlsh.

Risulta chì MySQL hà cambiatu a manera chì rapprisentanu dati per i campi decimali (int, tinyint, etc.), cusì mysql-server usa un modu diversu per almacenà. Se a vostra basa di dati inizialmente era in a versione 5.5 o 5.1, è dopu avete aghjurnatu à 5.7, allora pudete bisognu di fà OPTIMIZE per certi tavulini. Allora MySQL aghjurnà i schedarii di dati, trasferendu à u formatu di almacenamiento attuale.

Pudete ancu verificà questu cù l'utilità 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',
...

se field_type Se tenete uguali à 0, u vechju tipu hè utilizatu in a tavula - avete bisognu di fà OPTIMIZE. Tuttavia, se u valore hè 246, avete digià un novu tipu. Più infurmazione nantu à i tipi pò esse truvata in codice.

Inoltre, in stu bug Avemu cunsiderà a seconda raghjone pussibile, chì ci hà ignoratu: l'absenza di tavule InnoDB in a tabella di u sistema. INNODB_SYS_TABLESPACES, se elli, tavule, sò stati creati in a versione 5.1. Per evitari prublemi quandu aghjurnà, pudete aduprà script SQL attaccatu.

Perchè ùn avemu micca tali prublemi in dev? A basa di dati hè periodicamente copiata da a produzzione - cusì, e tavule sò ricreate.

Sfurtunatamente, nantu à una basa di dati veramente grande chì travaglia, ùn puderà micca solu piglià è eseguisce un universale OPTIMIZE. percona-toolkit aiuterà quì: l'utilità pt-online-schema-change hè eccellente per l'operazione OPTIMIZE in linea.

U pianu aghjurnatu pareva cusì:

Ottimisate tutte e tavule.
Aghjurnate e basa di dati.

Per verificà è à u stessu tempu scopre u tempu d'aghjurnamentu, avemu disattivatu una di e rèpliche è eseguite u cumandimu seguitu per tutti i tavulini:

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

I tavulini sò aghjurnati senza chjusi longu per u fattu chì l'utilità crea una nova tavola temporale in quale copia dati da a tavola principale. À u mumentu chì e duie tavule sò identiche, a tavola originale hè chjusa è rimpiazzata cù a nova. In u nostru casu, una prova di prova hà dimustratu chì duverebbe circa un ghjornu per aghjurnà tutte e tavule, ma a copia di dati hà causatu troppu carica nantu à i dischi.

Per evitari questu, in a pruduzzione aghjunghjemu l'argumentu à u cumandamentu --sleep cù un valore di 10 - stu paràmetru aghjusta a durata d'attesa dopu à trasfiriri un batch di dati à una nova tavola. In questu modu, pudete riduce a carica se l'applicazione attuale in esecuzione richiede u tempu di risposta.

Dopu avè realizatu l'ottimisazione, l'aghjurnamentu hè successu.

... ma micca cumplettamente !

In una meza ora dopu l'aghjurnamentu, u cliente hè ghjuntu cù un prublema. A basa di dati hà travagliatu assai stranu: periòdicamenti cuminciaru resetta a cunnessione. Eccu ciò chì pareva in u monitoraghju:

A screenshot mostra un gràficu sawtooth per via di u fattu chì alcuni di i fili di u servitore MySQL s'hè lampatu periodicamente cù un errore. Errori apparsu in l'applicazione:

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

Una inspezione rapida di i logs hà revelatu chì u daemon mysqld ùn pudia micca ottene e risorse necessarie da u sistema operatore. Mentri sorta l'errori, avemu scupertu in u sistema schedarii di pulitica "orfani" di 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

Questi schedari sò stati creati quandu l'aghjurnamentu à MySQL 5.7 un paru d'anni fà è appartenenu à un pacchettu eliminatu. L'eliminazione di i fugliali è riavvia u serviziu di apparmor risolve u prublema:

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

In cunclusioni

Qualchese, ancu l'operazione più simplice, pò purtà à prublemi inespettati. È ancu avè un pianu ben pensatu ùn guarantisci micca sempre u risultatu previstu. Avà, ogni pianu di aghjurnamentu chì a nostra squadra hà ancu include a pulizia obligatoria di i fugliali innecessarii chì puderianu apparsu per via di l'azzioni recenti.

È cù sta creatività grafica pocu prufessiunale, vogliu dì un ringraziu enormu à Percona per i so prudutti eccellenti!