Att flytta från MySQL 5.7 till MySQL 8.0

April 2018 är inte bara ett datum för MySQL-världen. MySQL 8.0 släpptes där, och mer än ett år efter är det förmodligen dags att överväga att migrera till den här nya versionen.

MySQL 8.0 har viktiga prestanda- och säkerhetsförbättringar, och precis som vid all migrering till en ny databasversion finns det flera saker att ta hänsyn till innan man börjar producera för att undvika svåra problem som dataförlust, överdriven driftstopp, eller till och med en återställning under migreringsuppgiften.

I den här bloggen kommer vi att nämna några av de nya MySQL 8.0-funktionerna, några föråldrade saker och vad du behöver tänka på innan du migrerar.

Vad är nytt i MySQL 8.0?

Låt oss nu sammanfatta några av de viktigaste funktionerna som nämns i den officiella dokumentationen för denna nya MySQL-version.

MySQL innehåller en transaktionsdatalexikon som lagrar information om databasobjekt.
En atomic DDL-sats kombinerar datalexikonuppdateringar, lagringsmotoroperationer och binära loggskrivningar associerade med en DDL-operation till en enda atomär transaktion.
MySQL-servern utför automatiskt alla nödvändiga uppgraderingsuppgifter vid nästa uppstart för att uppgradera systemtabellerna i mysql-schemat, såväl som objekt i andra scheman såsom sys-schemat och användarscheman. Det är inte nödvändigt för DBA att anropa mysql_upgrade.
Den stöder skapande och hantering av resursgrupper och tillåter att tilldela trådar som körs på servern till särskilda grupper så att trådar körs enligt de resurser som är tillgängliga för gruppen.
Tabellkryptering kan nu hanteras globalt genom att definiera och upprätthålla standardkryptering. Variabeln default_table_encryption definierar en krypteringsstandard för nyskapade scheman och allmänt tabellutrymme. Standardvärden för kryptering upprätthålls genom att aktivera variabeln table_encryption_privilege_check.
Standarduppsättningen av tecken har ändrats från latin1 till utf8mb4.
Den stöder användningen av uttryck som standardvärden i datatypspecifikationer. Detta inkluderar användningen av uttryck som standardvärden för datatyperna BLOB, TEXT, GEOMETRY och JSON.
Felloggningen skrevs om för att använda MySQL-komponentarkitekturen. Traditionell felloggning implementeras med inbyggda komponenter, och loggning med systemloggen implementeras som en laddningsbar komponent.
En ny typ av säkerhetskopieringslås tillåter DML under en onlinesäkerhetskopiering samtidigt som man förhindrar operationer som kan resultera i en inkonsekvent ögonblicksbild. Det nya säkerhetskopieringslåset stöds av syntaxen LOCK INSTANCE FOR BACKUP och UNLOCK INSTANCE. BACKUP_ADMIN-behörigheten krävs för att använda dessa uttalanden.
MySQL Server tillåter nu att en TCP/IP-port konfigureras specifikt för administrativa anslutningar. Detta ger ett alternativ till den enda administrativa anslutningen som är tillåten på nätverksgränssnitten som används för vanliga anslutningar även när max_connections-anslutningar redan är etablerade.
Den stöder osynliga index. Detta index används inte av optimeraren och gör det möjligt att testa effekten av att ta bort ett index på frågeprestanda, utan att ta bort det.
Document Store för utveckling av både SQL- och NoSQL-dokumentapplikationer med en enda databas.
MySQL 8.0 gör det möjligt att bevara globala, dynamiska servervariabler med hjälp av kommandot SET PERSIST istället för det vanliga SET GLOBAL.

MySQL-säkerhet och kontohantering

Eftersom det finns många förbättringar relaterade till säkerhet och användarhantering kommer vi att lista dem i ett separat avsnitt.

Beviljandetabellerna i mysql-systemdatabasen är nu InnoDB-tabeller.
Det nya plugin-programmet för caching_sha2_password-autentisering är nu standardautentiseringsmetoden i MySQL 8.0. Den implementerar SHA-256-lösenordshashing, men använder cachning för att åtgärda latensproblem vid anslutning. Det ger säkrare lösenordskryptering än plugin-programmet mysql_native_password och ger bättre prestanda än sha256_password.
MySQL stöder nu roller, som kallas samlingar av privilegier. Roller kan ha privilegier beviljade och återkallade från dem, och de kan beviljas till och återkallas från användarkonton.
MySQL har nu information om lösenordshistorik, vilket möjliggör restriktioner för återanvändning av tidigare lösenord.
Det gör det möjligt för administratörer att konfigurera användarkonton så att för många på varandra följande inloggningsfel på grund av felaktiga lösenord orsakar tillfällig kontolåsning.

InnoDB-förbättringar

Som föregående punkt finns det också många förbättringar relaterade till detta ämne, så vi listar dem också i ett separat avsnitt.

Det aktuella maximala räknarvärdet för automatisk inkrementering skrivs till redo-loggen varje gång värdet ändras och sparas i en motor-privat systemtabell på varje kontrollpunkt. Dessa ändringar gör att det nuvarande maximala värdet för automatisk inkrementräknare kvarstår över serverstarter
När man stöter på korruption i indexträdet, skriver InnoDB en korruptionsflagga till redo-loggen, vilket gör korruptionsflaggan kraschsäker. InnoDB skriver också korruptionsflaggadata i minnet till en motor-privat systemtabell på varje kontrollpunkt. Under återställning läser InnoDB korruptionsflaggor från båda platserna och slår samman resultat innan tabell- och indexobjekt i minnet markeras som korrupta.
En ny dynamisk variabel, innodb_deadlock_detect, kan användas för att inaktivera deadlock-detektering. På system med hög samtidighet kan detektering av dödläge orsaka en avmattning när flera trådar väntar på samma lås. Ibland kan det vara mer effektivt att inaktivera detektering av dödläge och förlita sig på innodb_lock_wait_timeout-inställningen för återställning av transaktioner när ett dödläge uppstår.
InnoDB temporära tabeller skapas nu i den delade temporära tabellutrymmet, ibtmp1.
mysql-systemtabeller och dataordbokstabeller skapas nu i en enda InnoDB-tabellutrymmesfil med namnet mysql.ibd i MySQL-datakatalogen. Tidigare skapades dessa tabeller i individuella InnoDB-tabellutrymmesfiler i mysql-databaskatalogen.
Som standard finns ångraloggar nu i två ångra tabellutrymmen som skapas när MySQL-instansen initieras. Ångra-loggar skapas inte längre i systemets tabellutrymme.
Den nya variabeln innodb_dedicated_server, som är inaktiverad som standard, kan användas för att få InnoDB att automatiskt konfigurera följande alternativ enligt mängden minne som detekteras på servern:innodb_buffer_pool_size, innodb_log_file_size och innodb_flush_method. Det här alternativet är avsett för MySQL-serverinstanser som körs på en dedikerad server.
Tablespace-filer kan flyttas eller återställas till en ny plats medan servern är offline med alternativet innodb_directories.

Låt oss nu ta en titt på några av funktionerna som du inte längre bör använda i den här nya MySQL-versionen.

Vad är utfasat i MySQL 8.0?

Följande funktioner är utfasade och kommer att tas bort i en framtida version.

Teckenuppsättningen utf8mb3 är utfasad. Använd utf8mb4 istället.
Eftersom caching_sha2_password är standardinsticksprogrammet för autentisering i MySQL 8.0 och tillhandahåller en superset av funktionerna för autentiseringspluginen sha256_password, är sha256_password utfasad.
Insticksprogrammet validate_password har omimplementerats för att använda serverkomponentens infrastruktur. Plugin-formen för validate_password är fortfarande tillgänglig men är utfasad.
ENGINE-satsen för satserna ALTER TABLESPACE och DROP TABLESPACE.
PAD_CHAR_TO_FULL_LENGTH SQL-läge.
AUTO_INCREMENT-stöd är utfasat för kolumner av typen FLOAT och DOUBLE (och eventuella synonymer). Överväg att ta bort attributet AUTO_INCREMENT från sådana kolumner, eller konvertera dem till en heltalstyp.
Attributet UNSIGNED är föråldrat för kolumner av typen FLOAT, DOUBLE och DECIMAL (och eventuella synonymer). Överväg att använda en enkel CHECK-begränsning istället för sådana kolumner.
FLOAT(M,D) och DOUBLE(M,D)-syntax för att ange antalet siffror för kolumner av typen FLOAT och DOUBLE (och eventuella synonymer) är ett icke-standardiserat MySQL-tillägg. Denna syntax är utfasad.
Den icke-standardiserade C-stilen &&, || och ! operatorer som är synonymer för standardoperatorerna SQL AND, OR och NOT, är utfasade. Applikationer som använder icke-standardoperatorer bör justeras för att använda standardoperatorer.
mysql_upgrade-klienten är utfasad eftersom dess möjligheter för att uppgradera systemtabellerna i mysql-systemschemat och objekt i andra scheman har flyttats till MySQL-servern.
Mysql_upgrade_info-filen, som skapas datakatalog och används för att lagra MySQL-versionsnumret.
Systemvariabeln relay_log_info_file och alternativet --master-info-file är utfasade. Tidigare användes dessa för att ange namnet på relälogginformationsloggen och huvudinformationsloggen när relay_log_info_repository=FILE och master_info_repository=FILE ställdes in, men dessa inställningar har föråldrats. Användningen av filer för relälogginformationsloggen och huvudinformationsloggen har ersatts av kraschsäkra slavtabeller, som är standard i MySQL 8.0.
Användningen av miljövariabeln MYSQL_PWD för att ange ett MySQL-lösenord är utfasad.

Och nu, låt oss ta en titt på några av funktionerna som du måste sluta använda i den här MySQL-versionen.

Vad togs bort i MySQL 8.0?

Följande funktioner har tagits bort i MySQL 8.0.

Systemvariabeln innodb_locks_unsafe_for_binlog togs bort. Isoleringsnivån READ COMMITTED ger liknande funktionalitet.
Använda GRANT för att skapa användare. Använd istället CREATE USER. Att följa denna praxis gör NO_AUTO_CREATE_USER SQL-läget oväsentligt för GRANT-satser, så det tas också bort, och ett fel skrivs nu till serverloggen när närvaron av detta värde för alternativet sql_mode i optionsfilen hindrar mysqld från att starta.
Använda GRANT för att ändra kontoegenskaper andra än behörighetstilldelningar. Detta inkluderar autentisering, SSL och resursbegränsningsegenskaper. Skapa istället sådana egenskaper när kontot skapas med CREATE USER eller ändra dem efteråt med ALTER USER.
IDENTIFIERAD AV LÖSENORD 'auth_string'-syntax för CREATE USER och GRANT. Använd istället IDENTIFIED WITH auth_plugin AS 'auth_string' för CREATE USER och ALTER USER, där värdet 'auth_string' är i ett format som är kompatibelt med det namngivna insticksprogrammet.
PASSWORD()-funktionen. Dessutom betyder borttagning av PASSWORD() att SET PASSWORD ... =PASSWORD('auth_string') syntax inte längre är tillgänglig.
Systemvariabeln old_passwords.
FLUSH QUERY Cache och RESET QUERY Cache.
Dessa systemvariabler:query_cache_limit, query_cache_min_res_unit, query_cache_size, query_cache_type, query_cache_wlock_invalidate.
Dessa statusvariabler:Qcache_free_blocks, Qcache_free_memory, Qcache_hits, Qcache_inserts, Qcache_lowmem_prunes, Qcache_not_cached, Qcache_queries_in_cache, Qcache_total_blocks.
Dessa trådtillstånd:kontrollera privilegier på cachad fråga, kontrollera frågecache för en fråga, ogiltigförklara frågecacheposter, skicka cachelagrat resultat till klienten, lagra resultat i frågecache, Väntar på frågecachelås.
Systemvariablerna tx_isolation och tx_read_only har tagits bort. Använd transaktionsisolering och transaktions_skrivskyddad istället.
Systemvariabeln sync_frm har tagits bort eftersom .frm-filer har blivit föråldrade.
Systemvariabeln secure_auth och klientalternativet --secure-auth har tagits bort. Alternativet MYSQL_SECURE_AUTH för mysql_options() C API-funktionen togs bort.
Systemvariabeln log_warnings och --log-warnings-serveralternativet har tagits bort. Använd systemvariabeln log_error_verbosity istället.
Det globala omfånget för systemvariabeln sql_log_bin togs bort. sql_log_bin har endast sessionsomfång, och applikationer som är beroende av åtkomst till @@GLOBAL.sql_log_bin bör justeras.
Systemvariablerna för oanvända date_format, datetime_format, time_format och max_tmp_tables tas bort.
De utfasade ASC- eller DESC-kvalificeringarna för GROUP BY-satser tas bort. Frågor som tidigare förlitade sig på GROUP BY-sortering kan ge resultat som skiljer sig från tidigare MySQL-versioner. För att producera en given sorteringsordning, ange en ORDER BY-sats.
Parsern behandlar inte längre \N som en synonym för NULL i SQL-satser. Använd NULL istället. Denna ändring påverkar inte import- eller exportoperationer för textfiler som utförs med LOAD DATA eller SELECT ... INTO OUTFILE, för vilken NULL fortsätter att representeras av \N.
Alternativen --ssl och --ssl-verify-server-cert på klientsidan har tagits bort. Använd --ssl-mode=REQUIRED istället för --ssl=1 eller --enable-ssl. Använd --ssl-mode=DISABLED istället för --ssl=0, --skip-ssl eller --disable-ssl. Använd --ssl-mode=VERIFY_IDENTITY istället för --ssl-verify-server-cert-alternativ.
Programmet mysql_install_db har tagits bort från MySQL-distributioner. Datakataloginitiering bör utföras genom att anropa mysqld med alternativet --initialize eller --initialize-insecure istället. Dessutom togs --bootstrap-alternativet för mysqld som användes av mysql_install_db bort, och INSTALL_SCRIPTDIR CMake-alternativet som styrde installationsplatsen för mysql_install_db togs bort.
Verktyget mysql_plugin togs bort. Alternativen inkluderar att ladda insticksprogram vid serverstart med alternativen --plugin-load eller --plugin-load-add, eller vid körning med INSTALL PLUGIN-satsen.
Resolveip-verktyget har tagits bort. nslookup, host eller dig kan användas istället.

Det finns många nya, utfasade och borttagna funktioner. Du kan kontrollera den officiella webbplatsen för mer detaljerad information.

Överväganden innan du migrerar till MySQL 8.0

Låt oss nu nämna några av de viktigaste sakerna att tänka på innan vi migrerar till den här MySQL-versionen.

Autentiseringsmetod

Som vi nämnde är caching_sha2_password inte standardautentiseringsmetoden, så du bör kontrollera om din applikation/anslutning stöder det. Om inte, låt oss se hur du kan ändra standardautentiseringsmetoden och användarverifieringsinsticksprogrammet till 'mysql_native_password' igen.

För att ändra standard autentiseringsmetod, redigera my.cnf-konfigurationsfilen och lägg till/redigera följande rad:

$ vi /etc/my.cnf

[mysqld]

default_authentication_plugin=mysql_native_password

För att ändra insticksprogrammet för användarautentisering, kör följande kommando med en behörig användare:

$ mysql -p

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

Är hur som helst, dessa ändringar är inte en permanent lösning eftersom den gamla autentiseringen snart kan fasas ut, så du bör ta hänsyn till det för en framtida databasuppgradering.

Också rollerna är en viktig egenskap här. Du kan minska de individuella privilegierna genom att tilldela den till en roll och lägga till motsvarande användare där.

Du kan till exempel skapa en ny roll för marknadsförings- och utvecklarteamen:

$ mysql -p

CREATE ROLE 'marketing', 'developers';

Tilldela privilegier till dessa nya roller:

GRANT SELECT ON *.* TO 'marketing';

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

Och tilldela sedan rollen till användarna:

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

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

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

Och det är allt. Du har följande behörigheter:

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)

Teckenuppsättningar

Eftersom den nya standardteckenuppsättningen är utf8mb4, bör du se till att du inte använder standardtecken eftersom den kommer att ändras.

För att undvika vissa problem bör du ange variablerna character_set_server och collation_server i konfigurationsfilen my.cnf.

$ vi /etc/my.cnf

[mysqld]

character_set_server=latin1

collation_server=latin1_swedish_ci

MyISAM Engine

MySQL-privilegietabellerna i MySQL-schemat flyttas till InnoDB. Du kan skapa en tabellmotor=MyISAM, och den kommer att fungera som tidigare, men att hantera en MyISAM-tabell till en körande MySQL-server kommer inte att fungera eftersom den inte kommer att upptäckas.

Partitionering

Det får inte finnas några partitionerade tabeller som använder en lagringsmotor som inte har inbyggt partitioneringsstöd. Du kan köra följande fråga för att verifiera denna punkt.

$ mysql -p

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

Om du behöver ändra motorn för en tabell kan du köra:

ALTER TABLE table_name ENGINE = INNODB;

Uppgraderingskontroll

Som ett sista steg kan du köra mysqlcheck-kommandot med check-upgrade-flaggan för att bekräfta om allt ser bra ut.

$ 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

Det finns flera saker att kontrollera innan du utför uppgraderingen. Du kan kontrollera den officiella MySQL-dokumentationen för mer detaljerad information.

Uppgraderingsmetoder

Det finns olika sätt att uppgradera MySQL 5.7 till 8.0. Du kan använda uppgraderingen på plats eller till och med skapa en replikeringsslav i den nya versionen, så att du kan marknadsföra den senare.

Men innan du uppgraderar måste steg 0 säkerhetskopiera dina data. Säkerhetskopieringen bör innehålla alla databaser inklusive systemdatabaserna. Så om det är något problem kan du återställa så fort som möjligt.

Ett annat alternativ, beroende på tillgängliga resurser, kan vara att skapa en kaskadreplikering MySQL 5.7 -> MySQL 8.0 -> MySQL 5.7, så efter att ha marknadsfört den nya versionen, om något gick fel, kan du marknadsföra slavnod med den gamla versionen tillbaka. Men det kan vara farligt om det var något problem med data, så säkerhetskopieringen är ett måste innan den.

För att alla metoder ska användas krävs det en testmiljö för att verifiera att applikationen fungerar utan problem med den nya MySQL 8.0-versionen.

Slutsats

Mer än 1 år efter MySQL 8.0-släppet är det dags att börja fundera på att migrera din gamla MySQL-version, men som tur är, eftersom slutet på stödet för MySQL 5.7 är 2023, har du tid att skapa en migreringsplan och testa applikationens beteende utan brådska. Det är nödvändigt att spendera lite tid i det teststeget för att undvika problem efter migreringen.

Att flytta från MySQL 5.7 till MySQL 8.0 - Vad du bör veta