Skift fra MySQL 5.7 til MySQL 8.0 - Hvad du bør vide

April 2018 er ikke kun en dato for MySQL-verdenen. MySQL 8.0 blev udgivet der, og mere end 1 år efter er det sandsynligvis tid til at overveje at migrere til denne nye version.

MySQL 8.0 har vigtige ydeevne- og sikkerhedsforbedringer, og som i al migrering til en ny databaseversion, er der flere ting, du skal tage højde for, før du går i produktion for at undgå vanskelige problemer som datatab, overdreven nedetid eller endda en tilbagerulning under migreringsopgaven.

I denne blog vil vi nævne nogle af de nye MySQL 8.0-funktioner, nogle forældede ting, og hvad du skal huske på, før du migrerer.

Hvad er nyt i MySQL 8.0?

Lad os nu opsummere nogle af de vigtigste funktioner, der er nævnt i den officielle dokumentation for denne nye MySQL-version.

• MySQL inkorporerer en transaktionsdataordbog, der gemmer information om databaseobjekter.
• En atomisk DDL-sætning kombinerer dataordbogsopdateringer, lagermotoroperationer og binære logskrivninger, der er forbundet med en DDL-operation, til en enkelt atomtransaktion.
• MySQL-serveren udfører automatisk alle nødvendige opgraderingsopgaver ved næste opstart for at opgradere systemtabellerne i mysql-skemaet, såvel som objekter i andre skemaer såsom sys-skemaet og brugerskemaer. Det er ikke nødvendigt for DBA at kalde mysql_upgrade.
• Det understøtter oprettelse og styring af ressourcegrupper og tillader at tildele tråde, der kører på serveren, til bestemte grupper, så tråde udføres i overensstemmelse med de ressourcer, der er tilgængelige for gruppen.
• Tabelkryptering kan nu administreres globalt ved at definere og håndhæve krypteringsstandarder. Variablen default_table_encryption definerer en krypteringsstandard for nyoprettede skemaer og generelt tablespace. Krypteringsstandarder håndhæves ved at aktivere variablen table_encryption_privilege_check.
• Standardtegnsættet er ændret fra latin1 til utf8mb4.
• Det understøtter brugen af ​​udtryk som standardværdier i datatypespecifikationer. Dette inkluderer brugen af ​​udtryk som standardværdier for datatyperne BLOB, TEXT, GEOMETRY og JSON.
• Fejllogning blev omskrevet til at bruge MySQL-komponentarkitekturen. Traditionel fejllogning implementeres ved hjælp af indbyggede komponenter, og logning ved hjælp af systemloggen implementeres som en indlæsbar komponent.
• En ny type sikkerhedskopieringslås tillader DML under en online sikkerhedskopiering og forhindrer samtidig handlinger, der kan resultere i et inkonsekvent øjebliksbillede. Den nye sikkerhedskopieringslås understøttes af syntaksen LÅS FORESLÅR TIL SIKKERHEDSKOPIER og LÅS OPLYSNINGER. BACKUP_ADMIN-privilegiet er påkrævet for at bruge disse udsagn.
• MySQL Server tillader nu, at en TCP/IP-port konfigureres specifikt til administrative forbindelser. Dette giver et alternativ til den enkelte administrative forbindelse, der er tilladt på de netværksgrænseflader, der bruges til almindelige forbindelser, selv når max_connections-forbindelser allerede er etableret.
• Det understøtter usynlige indekser. Dette indeks bruges ikke af optimeringsværktøjet og gør det muligt at teste effekten af ​​at fjerne et indeks på forespørgselsydeevne uden at fjerne det.
• Dokumentlager til udvikling af både SQL- og NoSQL-dokumentapplikationer ved hjælp af en enkelt database.
• MySQL 8.0 gør det muligt at bevare globale, dynamiske servervariabler ved at bruge kommandoen SET PERSIST i stedet for den sædvanlige SET GLOBAL.

MySQL-sikkerhed og kontostyring

Da der er mange forbedringer relateret til sikkerhed og brugeradministration, vil vi liste dem i et separat afsnit.

• Tildelingstabellerne i mysql-systemdatabasen er nu InnoDB-tabeller.
• Det nye caching_sha2_password-godkendelsesplugin er nu standardgodkendelsesmetoden i MySQL 8.0. Den implementerer SHA-256 adgangskode-hashing, men bruger caching til at løse problemer med ventetid på forbindelsestidspunktet. Det giver mere sikker adgangskodekryptering end mysql_native_password-plugin'et og giver bedre ydeevne end sha256_password.
• MySQL understøtter nu roller, som kaldes samlinger af privilegier. Roller kan have privilegier tildelt og tilbagekaldt fra dem, og de kan tildeles til og tilbagekaldes fra brugerkonti.
• MySQL vedligeholder nu information om adgangskodehistorik, hvilket muliggør begrænsninger for genbrug af tidligere adgangskoder.
• Det gør det muligt for administratorer at konfigurere brugerkonti, således at for mange på hinanden følgende login-fejl på grund af forkerte adgangskoder forårsager midlertidig kontolåsning.

InnoDB-forbedringer

Som det foregående punkt er der også mange forbedringer relateret til dette emne, så vi vil også liste dem i et separat afsnit.

• Den aktuelle maksimale automatiske stigningstællerværdi skrives til redo-loggen, hver gang værdien ændres, og gemmes i en motor-privat systemtabel på hvert kontrolpunkt. Disse ændringer gør den nuværende maksimale automatiske tællerværdi vedvarende på tværs af servergenstarter
• Når man støder på korruption i indekstræet, skriver InnoDB et korruptionsflag til redo-loggen, hvilket gør korruptionsflaget nedbrudsikkert. InnoDB skriver også korruptionsflagdata i hukommelsen til en motor-privat systemtabel på hvert kontrolpunkt. Under gendannelse læser InnoDB korruptionsflag fra begge lokationer og fletter resultater, før de markerer tabel- og indeksobjekter i hukommelsen som korrupte.
• En ny dynamisk variabel, innodb_deadlock_detect, kan bruges til at deaktivere deadlock-detektion. På systemer med høj samtidighed kan deadlock-detektion forårsage en opbremsning, når adskillige tråde venter på den samme lås. Til tider kan det være mere effektivt at deaktivere deadlock-detektering og stole på innodb_lock_wait_timeout-indstillingen for tilbagerulning af transaktioner, når der opstår en deadlock.
• InnoDB midlertidige tabeller oprettes nu i det delte midlertidige tablespace, ibtmp1.
• mysql-systemtabeller og dataordbogstabeller oprettes nu i en enkelt InnoDB-tablespace-fil ved navn mysql.ibd i MySQL-datamappen. Tidligere blev disse tabeller oprettet i individuelle InnoDB tablespace-filer i mysql-databasebiblioteket.
• Som standard findes fortryd-logfiler nu i to fortryd-tablespaces, der oprettes, når MySQL-instansen initialiseres. Fortryd-logfiler oprettes ikke længere i systemets tablespace.
• Den nye innodb_dedicated_server-variabel, som er deaktiveret som standard, kan bruges til at få InnoDB til automatisk at konfigurere følgende muligheder i henhold til mængden af ​​hukommelse, der er fundet på serveren:innodb_buffer_pool_size, innodb_log_file_size og innodb_flush_method. Denne mulighed er beregnet til MySQL-serverforekomster, der kører på en dedikeret server.
• Tablespace-filer kan flyttes eller gendannes til en ny placering, mens serveren er offline ved at bruge indstillingen innodb_directories.

Lad os nu tage et kig på nogle af de funktioner, som du ikke længere bør bruge i denne nye MySQL-version.

Hvad er forældet i MySQL 8.0?

Følgende funktioner er forældede og vil blive fjernet i en fremtidig version.

• Utf8mb3-tegnsættet er forældet. Brug venligst utf8mb4 i stedet.
• Fordi caching_sha2_password er standardgodkendelsespluginnet i MySQL 8.0 og giver et supersæt af mulighederne for sha256_password-godkendelsespluginnet, er sha256_password forældet.
• validate_password-pluginnet er blevet genimplementeret til at bruge serverkomponentinfrastrukturen. Plugin-formen for validate_password er stadig tilgængelig, men er forældet.
• ENGINE-sætningen for ALTER TABLESPACE- og DROP TABLESPACE-sætningerne.
• PAD_CHAR_TO_FULL_LENGTH SQL-tilstand.
• AUTO_INCREMENT-understøttelse er forældet for kolonner af typen FLOAT og DOUBLE (og eventuelle synonymer). Overvej at fjerne AUTO_INCREMENT-attributten fra sådanne kolonner, eller konverter dem til en heltalstype.
• Attributten UNSIGNED er forældet for kolonner af typen FLOAT, DOUBLE og DECIMAL (og eventuelle synonymer). Overvej at bruge en simpel CHECK-begrænsning i stedet for sådanne kolonner.
• FLOAT(M,D) og DOUBLE(M,D) syntaks til at angive antallet af cifre for kolonner af typen FLOAT og DOUBLE (og eventuelle synonymer) er en ikke-standard MySQL-udvidelse. Denne syntaks er forældet.
• Den ikke-standardiserede C-stil &&, || og ! operatorer, der er synonymer for standard-SQL AND-, OR- og NOT-operatorerne, er forældet. Applikationer, der bruger ikke-standardoperatorerne, bør justeres til at bruge standardoperatorerne.
• mysql_upgrade-klienten er forældet, fordi dens muligheder for at opgradere systemtabellerne i mysql-systemskemaet og objekter i andre skemaer er blevet flyttet til MySQL-serveren.
• Mysql_upgrade_info-filen, som er oprettet datamappe og bruges til at gemme MySQL-versionsnummeret.
• Relay_log_info_file systemvariablen og --master-info-file indstillingen er forældet. Tidligere blev disse brugt til at angive navnet på relæloginfologgen og masterinfologgen, når relay_log_info_repository=FILE og master_info_repository=FILE blev indstillet, men disse indstillinger er blevet forældet. Brugen af ​​filer til relæloginfologgen og masterinfologgen er blevet afløst af nedbrudssikre slavetabeller, som er standard i MySQL 8.0.
• Brugen af ​​miljøvariablen MYSQL_PWD til at angive en MySQL-adgangskode er forældet.

Og nu, lad os tage et kig på nogle af de funktioner, som du skal stoppe med at bruge i denne MySQL-version.

Hvad blev fjernet i MySQL 8.0?

Følgende funktioner er blevet fjernet i MySQL 8.0.

• Systemvariablen innodb_locks_unsafe_for_binlog blev fjernet. Isolationsniveauet READ COMMITTED giver lignende funktionalitet.
• Brug af GRANT til at oprette brugere. Brug i stedet CREATE USER. At følge denne praksis gør NO_AUTO_CREATE_USER SQL-tilstanden uvæsentlig for GRANT-sætninger, så den fjernes også, og der skrives en fejl nu til serverloggen, når tilstedeværelsen af ​​denne værdi for sql_mode-indstillingen i optionsfilen forhindrer mysqld i at starte.
• Brug af GRANT til at ændre andre kontoegenskaber end privilegietildelinger. Dette inkluderer egenskaber for godkendelse, SSL og ressourcebegrænsning. Etabler i stedet sådanne egenskaber på tidspunktet for kontooprettelse med CREATE USER eller modificer dem efterfølgende med ALTER USER.
• IDENTIFICERET AF PASSWORD 'auth_string'-syntaks for CREATE USER og GRANT. Brug i stedet IDENTIFICERET MED auth_plugin AS 'auth_string' for CREATE USER og ALTER USER, hvor 'auth_string'-værdien er i et format, der er kompatibelt med det navngivne plugin.
• PASSWORD()-funktionen. Derudover betyder fjernelse af PASSWORD(), at SET PASSWORD ... =PASSWORD('auth_string') syntaks ikke længere er tilgængelig.
• Systemvariablen old_passwords.
• FLUSH QUERY Cache og RESET QUERY CACHE-sætningerne.
• Disse systemvariable:query_cache_limit, query_cache_min_res_unit, query_cache_size, query_cache_type, query_cache_wlock_invalidate.
• Disse statusvariabler:Qcache_free_blocks, Qcache_free_memory, Qcache_hits, Qcache_inserts, Qcache_lowmem_prunes, Qcache_not_cached, Qcache_queries_in_cache, Qcache_total_blocks.
• Disse trådtilstande:kontrol af privilegier på cachelagret forespørgsel, kontrol af forespørgselscache for en forespørgsel, ugyldiggørelse af forespørgselscacheposter, afsendelse af cachelagret resultat til klienten, lagring af resultat i forespørgselscache, Venter på forespørgselscachelås.
• Systemvariablerne tx_isolation og tx_read_only er blevet fjernet. Brug transaktionsisolation og transaktions_skrivebeskyttet i stedet.
• Systemvariablen sync_frm er blevet fjernet, fordi .frm-filer er blevet forældede.
• Secure_auth-systemvariablen og --secure-auth-klientindstillingen er blevet fjernet. MYSQL_SECURE_AUTH-indstillingen for mysql_options() C API-funktionen blev fjernet.
• log_warnings-systemvariablen og --log-warnings-serverindstillingen er blevet fjernet. Brug systemvariablen log_error_verbosity i stedet.
• Det globale omfang for systemvariablen sql_log_bin blev fjernet. sql_log_bin har kun sessionsomfang, og programmer, der er afhængige af adgang til @@GLOBAL.sql_log_bin, bør justeres.
• De ubrugte date_format, datetime_format, time_format og max_tmp_tables systemvariabler fjernes.
• De forældede ASC- eller DESC-kvalifikationer for GROUP BY-sætninger fjernes. Forespørgsler, der tidligere var afhængige af GROUP BY-sortering, kan give resultater, der adskiller sig fra tidligere MySQL-versioner. For at producere en given sorteringsrækkefølge skal du angive en ORDER BY-klausul.
• Parseren behandler ikke længere \N som et synonym for NULL i SQL-sætninger. Brug NULL i stedet. Denne ændring påvirker ikke tekstfilimport eller eksporthandlinger udført med LOAD DATA eller SELECT ... INTO OUTFILE, for hvilken NULL fortsat er repræsenteret af \N.
• Indstillingerne --ssl og --ssl-verify-server-cert på klientsiden er blevet fjernet. Brug --ssl-mode=KRÆVET i stedet for --ssl=1 eller --enable-ssl. Brug --ssl-mode=DISABLED i stedet for --ssl=0, --skip-ssl eller --disable-ssl. Brug --ssl-mode=VERIFY_IDENTITY i stedet for --ssl-verify-server-cert-indstillinger.
• Mysql_install_db-programmet er blevet fjernet fra MySQL-distributioner. Initialisering af databibliotek bør udføres ved at kalde mysqld med --initialize eller --initialize-insecure muligheden i stedet. Derudover blev --bootstrap-indstillingen for mysqld, der blev brugt af mysql_install_db, fjernet, og INSTALL_SCRIPTDIR CMake-indstillingen, der styrede installationsplaceringen for mysql_install_db, blev fjernet.
• Mysql_plugin-værktøjet blev fjernet. Alternativer omfatter indlæsning af plugins ved serverstart ved hjælp af --plugin-load eller --plugin-load-add mulighed, eller ved kørsel ved brug af INSTALL PLUGIN-sætningen.
• Resolveip-værktøjet er fjernet. nslookup, host eller dig kan bruges i stedet.

Der er en masse nye, forældede og fjernede funktioner. Du kan tjekke den officielle hjemmeside for mere detaljeret information.

Overvejelser før migrering til MySQL 8.0

Lad os nu nævne nogle af de vigtigste ting, du skal overveje, før du migrerer til denne MySQL-version.

Godkendelsesmetode

Som vi nævnte, er caching_sha2_password ikke standardgodkendelsesmetoden, så du bør tjekke, om din applikation/forbindelse understøtter det. Hvis ikke, så lad os se, hvordan du kan ændre standardgodkendelsesmetoden og brugergodkendelsespluginet til 'mysql_native_password' igen.

For at ændre standardgodkendelsesmetoden skal du redigere my.cnf-konfigurationsfilen og tilføje/redigere følgende linje:

$ vi /etc/my.cnf

[mysqld]

default_authentication_plugin=mysql_native_password

For at ændre brugergodkendelsespluginnet skal du køre følgende kommando med en privilegeret bruger:

$ mysql -p

ALTER USER ‘username’@’hostname’ IDENTIFIED WITH ‘mysql_native_password’ BY ‘password’;

Alligevel er disse ændringer ikke en permanent løsning, da den gamle godkendelse snart kan blive forældet, så du bør tage det i betragtning ved en fremtidig databaseopgradering.

Også rollerne er en vigtig funktion her. Du kan reducere de individuelle privilegier ved at tildele den til en rolle og tilføje de tilsvarende brugere der.

Du kan f.eks. oprette en ny rolle for marketing- og udviklerteamet:

$ mysql -p

CREATE ROLE 'marketing', 'developers';

Tildel privilegier til disse nye roller:

GRANT SELECT ON *.* TO 'marketing';

GRANT ALL PRIVILEGES ON *.* TO 'developers';

Og tildel derefter rollen til brugerne:

GRANT 'marketing' TO 'marketing1'@'%';

GRANT 'marketing' TO 'marketing2'@'%';

GRANT 'developers' TO 'developer1'@'%';

Og det er det. Du har følgende privilegier:

SHOW GRANTS FOR 'marketing1'@'%';

+-------------------------------------------+

| Grants for [email protected]%                   |

+-------------------------------------------+

| GRANT USAGE ON *.* TO `marketing1`@`%`    |

| GRANT `marketing`@`%` TO `marketing1`@`%` |

+-------------------------------------------+

2 rows in set (0.00 sec)

SHOW GRANTS FOR 'marketing';

+----------------------------------------+

| Grants for [email protected]%                 |

+----------------------------------------+

| GRANT SELECT ON *.* TO `marketing`@`%` |

+----------------------------------------+

1 row in set (0.00 sec)

Tegnsæt

Da det nye standardtegnsæt er utf8mb4, bør du sikre dig, at du ikke bruger standardtegnsæt, da det vil ændre sig.

For at undgå nogle problemer bør du angive variablerne character_set_server og collation_server i my.cnf-konfigurationsfilen.

$ vi /etc/my.cnf

[mysqld]

character_set_server=latin1

collation_server=latin1_swedish_ci

MyISAM Engine

MySQL-privilegietabellerne i MySQL-skemaet flyttes til InnoDB. Du kan oprette en tabelmotor=MyISAM, og den vil fungere som før, men at kopiere en MyISAM-tabel ind i en kørende MySQL-server vil ikke fungere, fordi den ikke vil blive opdaget.

Partitionering

Der må ikke være partitionerede tabeller, der bruger en lagringsmotor, der ikke understøtter indbygget partitionering. Du kan køre følgende forespørgsel for at bekræfte dette punkt.

$ mysql -p

SELECT TABLE_SCHEMA, TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE ENGINE NOT IN ('innodb', 'ndbcluster') AND CREATE_OPTIONS LIKE '%partitioned%';

Hvis du har brug for at ændre motoren i en tabel, kan du køre:

ALTER TABLE table_name ENGINE = INNODB;

Opgraderingstjek

Som et sidste trin kan du køre mysqlcheck-kommandoen ved at bruge check-upgrade-flaget for at bekræfte, om alt ser fint ud.

$ mysqlcheck -uroot -p --all-databases --check-upgrade

Enter password:

mysql.columns_priv                                 OK

mysql.component                                    OK

mysql.db                                           OK

mysql.default_roles                                OK

mysql.engine_cost                                  OK

mysql.func                                         OK

mysql.general_log                                  OK

mysql.global_grants                                OK

mysql.gtid_executed                                OK

mysql.help_category                                OK

mysql.help_keyword                                 OK

mysql.help_relation                                OK

mysql.help_topic                                   OK

mysql.innodb_index_stats                           OK

mysql.innodb_table_stats                           OK

mysql.password_history                             OK

mysql.plugin                                       OK

mysql.procs_priv                                   OK

mysql.proxies_priv                                 OK

mysql.role_edges                                   OK

mysql.server_cost                                  OK

mysql.servers                                      OK

mysql.slave_master_info                            OK

mysql.slave_relay_log_info                         OK

mysql.slave_worker_info                            OK

mysql.slow_log                                     OK

mysql.tables_priv                                  OK

mysql.time_zone                                    OK

mysql.time_zone_leap_second                        OK

mysql.time_zone_name                               OK

mysql.time_zone_transition                         OK

mysql.time_zone_transition_type                    OK

mysql.user                                         OK

sys.sys_config                                     OK

world_x.city                                       OK

world_x.country                                    OK

world_x.countryinfo                                OK

world_x.countrylanguage                            OK

Der er flere ting, du skal tjekke, før du udfører opgraderingen. Du kan tjekke den officielle MySQL-dokumentation for mere detaljeret information.

Opgraderingsmetoder

Der er forskellige måder at opgradere MySQL 5.7 til 8.0. Du kan bruge opgraderingen på stedet eller endda oprette en replikeringsslave i den nye version, så du kan promovere den senere.

Men før du opgraderer, skal trin 0 sikkerhedskopiere dine data. Sikkerhedskopien bør omfatte alle databaserne inklusive systemdatabaserne. Så hvis der er noget problem, kan du rulle tilbage hurtigst muligt.

En anden mulighed, afhængigt af de tilgængelige ressourcer, kan være at oprette en kaskadereplikering MySQL 5.7 -> MySQL 8.0 -> MySQL 5.7, så efter at have promoveret den nye version, hvis noget gik galt, kan du promovere slave node med den gamle version tilbage. Men det kunne være farligt, hvis der var et eller andet problem med dataene, så sikkerhedskopieringen er et must før det.

For enhver metode, der skal bruges, er det nødvendigt et testmiljø for at verificere, at applikationen fungerer uden problemer med den nye MySQL 8.0-version.

Konklusion

Mere end 1 år efter MySQL 8.0-udgivelsen er det tid til at begynde at overveje at migrere din gamle MySQL-version, men heldigvis, da slutningen af ​​supporten til MySQL 5.7 er 2023, har du tid til at oprette en migrationsplan og teste applikationsadfærden uden hastværk. Det er nødvendigt at bruge lidt tid på det testtrin for at undgå problemer efter migrering.