Migrering fra Oracle til MySQL/Percona Server er ikke en triviel opgave. Selvom det bliver nemmere, især med ankomsten af MySQL 8.0 og Percona annoncerede Percona Server til MySQL 8.0 GA. Udover at planlægge din migrering fra Oracle til Percona Server, skal du sikre dig, at du forstår formålet og funktionaliteten for, hvorfor det skal være Percona Server.
Denne blog vil fokusere på migrering fra Oracle til Percona Server som dens specifikke måldatabase. Der er en side på Oracle-webstedet om SQL Developer Supplerende oplysninger til MySQL-migreringer, som kan bruges som reference for den planlagte migrering. Denne blog vil ikke dække den overordnede migrationsproces, da det er en lang proces. Men det vil forhåbentlig give tilstrækkelig baggrundsinformation til at tjene som en guide til din migreringsproces.
Da Percona Server er en forgrening af MySQL, er næsten alle funktioner, der følger med i MySQL, til stede i Percona Server. Så enhver reference til MySQL her gælder også for Percona Server. Vi har tidligere blogget om migrering af Oracle Database til PostgreSQL. Jeg gentager igen grundene til, at man ville overveje at migrere fra Oracle til en open source RDBMS såsom PostgreSQL eller Percona Server/MySQL/MariaDB.
- Omkostninger:Som du måske ved, er omkostningerne til Oracle-licensen meget dyre, og der er ekstra omkostninger til nogle funktioner som partitionering og høj tilgængelighed. Så alt i alt er det meget dyrt.
- Fleksibel open source-licensering og nem tilgængelighed fra offentlige cloud-udbydere som AWS.
- Drag fordel af open source-tilføjelser for at forbedre ydeevnen.
Planlægnings- og udviklingsstrategi
Migrering fra Oracle til Percona Server 8.0 kan være en smerte, da der er en masse nøglefaktorer, der skal overvejes og behandles. For eksempel kan Oracle køre på en Windows Server-maskine, men Percona Server understøtter ikke Windows. Selvom du kan kompilere det til Windows, tilbyder Percona ikke selv nogen support til Windows. Du skal også identificere dine databasearkitekturkrav, da Percona Server ikke er designet til OLAP (Online Analytical Processing) eller datawarehousing-applikationer. Percona Server/MySQL RDBMS passer perfekt til OLTP (Online Transaction Processing).
Ved at identificere nøgleaspektet af din databasearkitektur, for eksempel hvis din nuværende Oracle-arkitektur implementerer MAA (Maximum Available Architecture) med Data Guard ++ Oracle RAC (Real Application Cluster), bør du bestemme dens ækvivalens i Percona Server. Der er ikke noget direkte svar på dette i MySQL/Percona Server. Du kan dog vælge mellem en synkron replikering, en asynkron replikering (Percona XtraDB Cluster er stadig på version 5.7.x) eller med gruppereplikering. Så er der flere alternativer, som du kan implementere til din egen højtilgængelige løsning. For eksempel (for at nævne nogle få) ved at bruge Corosync/Pacemaker/DRBD/Linux-stak, eller ved at bruge MHA (MySQL High Availability), eller ved at bruge Keepalived/HaProxy/ProxySQL-stack, eller helt klart stole på ClusterControl, som understøtter Keepalved, HaProxy, ProxySQL, Garbd og Maxscale for dine løsninger med høj tilgængelighed.
På den anden side er spørgsmålet, du også skal overveje som en del af planen, "Hvordan vil Percona yde support, og hvem vil hjælpe os, når Percona Server selv støder på en fejl, eller hvor højt haster det, når vi har brug for hjælp?". En ting at overveje også er budget, hvis formålet med migrering fra virksomhedsdatabase til et open source RDBMS er på grund af omkostningsbesparelser.
Der er forskellige muligheder fra migrationsplanlægning til de ting, du skal gøre som en del af din udviklingsstrategi. Sådanne muligheder inkluderer kontakt med eksperter inden for MySQL/Percona Server-området, og det inkluderer os her på Severalnines. Der er masser af MySQL-konsulentfirmaer, der kan hjælpe dig igennem dette, da migration fra Oracle til MySQL kræver en masse ekspertise og knowhow inden for MySQL Server-området. Dette bør ikke være begrænset til databasen, men det bør dække ekspertise inden for skalerbarhed, redundans, sikkerhedskopier, høj tilgængelighed, sikkerhed, overvågning/observation, gendannelse og brug af missionskritiske systemer. Samlet set bør den have en forståelse af din arkitektoniske indsigt uden at afsløre fortroligheden af dine data.
Vurdering eller foreløbig kontrol
Sikkerhedskopiering af dine data inklusive konfigurationer eller opsætningsfiler, kernejusteringer, automatiseringsscripts må ikke glemmes. Det er en indlysende opgave, men før du migrerer, skal du altid sikre alt først, især når du flytter til en anden platform.
Du skal også vurdere, at dine applikationer følger de opdaterede softwarekonstruktionskonventioner og sikre, at de er platformagnostiske. Denne praksis kan være til din fordel, især når du flytter til en anden databaseplatform, såsom Percona Server til MySQL.
Vær opmærksom på, at det operativsystem, som Percona Server kræver, kan være en show-stopper, hvis din applikation og database kører på en Windows Server, og applikationen er Windows-afhængig; så kan det være meget arbejde! Husk altid, at Percona Server er på en anden platform:perfektion er muligvis ikke garanteret, men kan opnås tæt nok på.
Til sidst skal du sikre dig, at den målrettede hardware er designet til at fungere med Perconas serverkrav, eller at den i det mindste er fejlfri (se her). Du kan overveje at stressteste først med Percona Server, før du pålideligt flytter fra din Oracle-database.
Hvad du bør vide
Det er værd at bemærke, at i Percona Server / MySQL kan du oprette flere databaser, mens Oracle ikke kommer med den samme funktionalitet som MySQL.
I MySQL er et skema rent fysisk synonymt med en database. Du kan erstatte nøgleordet SCHEMA i stedet for DATABASE i MySQL SQL-syntaks, for eksempel ved at bruge CREATE SCHEMA i stedet for CREATE DATABASE; mens Oracle har en sondring af dette. Et skema repræsenterer kun en del af en database:tabellerne og andre objekter, der ejes af en enkelt bruger. Normalt er der en en-til-en-relation mellem instansen og databasen.
For eksempel, i en replikeringsopsætning, der svarer til Oracle (f.eks. Real Application Clusters eller RAC), har du dine flere forekomster adgang til en enkelt database. Dette lader dig starte Oracle på flere servere, men alle får adgang til de samme data. I MySQL kan du dog tillade adgang til flere databaser fra dine flere instanser og kan endda filtrere ud, hvilke databaser/skemaer du kan replikere til en MySQL-node.
Med henvisning fra en af vores tidligere blogs, gælder det samme princip, når vi taler om at konvertere din database med tilgængelige værktøjer fundet på internettet.
Der er ikke noget sådant værktøj, der kan 100% konvertere Oracle-database til Percona Server / MySQL; noget af det vil være manuelt arbejde.
Tjek de følgende afsnit for ting, som du skal være opmærksom på, når det kommer til migrering og verificering af det logiske SQL-resultat.
Data Type Mapping
MySQL / Percona Server har en række datatyper, der er næsten de samme som Oracle, men ikke så rige sammenlignet med Oracle. Men siden ankomsten af 5.7.8-versionen af MySQL, understøttes en indbygget JSON-datatype.
Nedenfor er dens datatype-ækvivalente repræsentation (tabelrepræsentation er taget herfra):
| Oracle | MySQL | |||
|---|---|---|---|---|
| 1 | BFILE | Pejler til binær fil, ⇐ 4G | VARCHAR(255) | |
| 2 | BINARY_FLOAT | 32-bit flydende kommanummer | FLYDE | |
| 3 | BINARY_DOUBLE | 64-bit flydende kommanummer | DOUBLE | |
| 4 | BLOB | Binært stort objekt, ⇐ 4G | LONGBLOB | |
| 5 | CHAR(n), CHARACTER(n) | streng med fast længde, 1 ⇐ n ⇐ 255 | CHAR(n), CHARACTER(n) | |
| 6 | CHAR(n), CHARACTER(n) | streng med fast længde, 256 ⇐ n ⇐ 2000 | VARCHAR(n) | |
| 7 | CLOB | Karakter stort objekt, ⇐ 4G | LONGTEXT | |
| 8 | DATO | Dato og tid | DATETIME | |
| 9 | DECIMAL(p,s), DEC(p,s) | Fastpunktnummer | DECIMAL(p,s), DEC(p,s) | |
| 10 | DObbel PRÆCISION | Flydende kommanummer | DObbel PRÆCISION | |
| 11 | FLOAT(p) | Flydende kommanummer | DOUBLE | |
| 12 | INTEGER, INT | 38 cifre heltal | INT | DECIMAL(38) |
| 13 | INTERVAL ÅR(p) TIL MÅNED | Datointerval | VARCHAR(30) | |
| 14 | INTERVALDAG(p) TIL SEKUND(ER) | Dag og tidsinterval | VARCHAR(30) | |
| 15 | LANG | Tegndata, ⇐ 2G | LONGTEXT | |
| 16 | LANG RAW | Binære data, ⇐ 2G | LONGBLOB | |
| 17 | NCHAR(n) | UTF-8-streng med fast længde, 1 ⇐ n ⇐ 255 | NCHAR(n) | |
| 18 | NCHAR(n) | UTF-8-streng med fast længde, 256 ⇐ n ⇐ 2000 | NVARCHAR(n) | |
| 19 | NCHAR VARIERENDE(n) | UTF-8-streng med varierende længde, 1 ⇐ n ⇐ 4000 | NCHAR VARIENDE(n) | |
| 20 | NCLOB | Unicode-streng med variabel længde, ⇐ 4G | NVARCHAR(maks.) | |
| 21 | NUMBER(s,0), NUMBER(p) | 8-bit heltal, 1 <=p <3 | TINYINT | (0 til 255) |
| 16-bit heltal, 3 <=p <5 | SMALLINT | |||
| 32-bit heltal, 5 <=p <9 | INT | |||
| 64-bit heltal, 9 <=p <19 | STORT | |||
| Fastpunktnummer, 19 <=p <=38 | DECIMAL(p) | |||
| 22 | ANTAL(p,s) | Fastpunktnummer, s> 0 | DECIMAL(p,s) | |
| 23 | NUMBER, NUMBER(*) | Flydende kommanummer | DOUBLE | |
| 24 | NUMERISK(p,s) | Fastpunktnummer | NUMERIC(p,s) | |
| 25 | NVARCHAR2(n) | UTF-8-streng med variabel længde, 1 ⇐ n ⇐ 4000 | NVARCHAR(n) | |
| 26 | RAW(n) | Binær streng med variabel længde, 1 ⇐ n ⇐ 255 | BINÆR(n) | |
| 27 | RAW(n) | Binær streng med variabel længde, 256 ⇐ n ⇐ 2000 | VARBINARY(n) | |
| 28 | RIGTIG | Flydende kommanummer | DOUBLE | |
| 29 | ROWID | Fysisk rækkeadresse | CHAR(10) | |
| 30 | SMALLINT | 38 cifre heltal | DECIMAL(38) | |
| 31 | TIMESTAMP(p) | Dato og tid med brøk | DATETIME(p) | |
| 32 | TIMESTAMP(p) MED TIDSZONE | Dato og tid med brøk og tidszone | DATETIME(p)  | |
| 33 | UROWID(n) | Logiske rækkeadresser, 1 ⇐ n ⇐ 4000 | VARCHAR(n) | |
| 34 | VARCHAR(n) | Snor med variabel længde, 1 ⇐ n ⇐ 4000 | VARCHAR(n) | |
| 35 | VARCHAR2(n) | Snor med variabel længde, 1 ⇐ n ⇐ 4000 | VARCHAR(n) | |
| 36 | XMLTYPE | XML-data | LONGTEXT | |
Datatypeattributter og muligheder:
| Oracle | MySQL |
| BYTE og CHAR kolonnestørrelse semantik | Størrelse er altid i tegn |
Transaktioner
Percona Server bruger XtraDB (en forbedret version af InnoDB) som sin primære lagermotor til håndtering af transaktionsdata; selvom forskellige lagringsmotorer kan være et alternativt valg til håndtering af transaktioner såsom TokuDB (forældet) og MyRocks lagringsmotorer.
Selvom der er fordele og fordele ved at bruge eller udforske MyRocks med XtraDB, er sidstnævnte mere robust og de facto storage-motor, som Percona Server bruger, og den er aktiveret som standard, så vi vil bruge denne storage-motor som grundlag for migrering mht. til transaktioner.
Som standard har Percona Server / MySQL autocommit variabel sat til ON, hvilket betyder, at du eksplicit skal håndtere transaktionsudsagn for at drage fordel af ROLLBACK for at ignorere ændringer eller udnytte SAVEPOINT.
Det er dybest set det samme koncept, som Oracle bruger med hensyn til commit, rollbacks og savepoints.
For eksplicitte transaktioner betyder det, at du skal bruge START TRANSACTION/BEGIN;
Ellers, hvis du er nødt til at deaktivere autocommit, skal du udtrykkeligt COMMIT hele tiden for dine udsagn, der kræver ændringer af dine data.
Dobbelt bord
MySQL har den dobbelte kompatibilitet med Oracle, som er beregnet til kompatibilitet af databaser ved hjælp af en dummy-tabel, nemlig DUAL.
Dette passer til Oracles brug af DUAL, så eventuelle eksisterende udsagn i din applikation, der bruger DUAL, kræver muligvis ingen ændringer ved migrering til Percona Server.
Oracle FROM-sætningen er obligatorisk for hver SELECT-sætning, så Oracle-databasen bruger DUAL-tabel til SELECT-sætning, hvor et tabelnavn ikke er påkrævet.
I MySQL er FROM-klausulen ikke obligatorisk, så DUAL-tabel er ikke nødvendig. DUAL-tabellen fungerer dog ikke helt på samme måde, som den gør for Oracle, men for simple SELECT'er i Percona Server er dette fint.
Se følgende eksempel nedenfor:
I Oracle,
SQL> DESC DUAL;
Name Null? Type
----------------------------------------- -------- ----------------------------
DUMMY VARCHAR2(1)
SQL> SELECT CURRENT_TIMESTAMP FROM DUAL;
CURRENT_TIMESTAMP
---------------------------------------------------------------------------
16-FEB-19 04.16.18.910331 AM +08:00 Men i MySQL:
mysql> DESC DUAL;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'DUAL' at line 1
mysql> SELECT CURRENT_TIMESTAMP FROM DUAL;
+---------------------+
| CURRENT_TIMESTAMP |
+---------------------+
| 2019-02-15 20:20:28 |
+---------------------+
1 row in set (0.00 sec) Bemærk:DESC DUAL syntaks virker ikke i MySQL, og resultaterne er også forskellige, da CURRENT_TIMESTAMP (bruger TIMESTAMP datatype) i MySQL ikke inkluderer tidszonen.
SYSDATE
Oracles SYSDATE-funktion er næsten den samme i MySQL.
MySQL returnerer dato og klokkeslæt og er en funktion, der kræver () (luk og åben parentes uden påkrævede argumenter. For at demonstrere dette nedenfor, her er Oracle og MySQL om brug af SYSDATE.
I Oracle returnerer brug af almindelig SYSDATE blot datoen på dagen uden klokkeslæt. Men for at få klokkeslæt og dato, brug TO_CHAR til at konvertere dato og klokkeslæt til det ønskede format; mens du i MySQL måske ikke har brug for det for at få datoen og klokkeslættet, da det returnerer begge dele.
Se eksempel nedenfor.
I Oracle:
SQL> SELECT TO_CHAR (SYSDATE, 'MM-DD-YYYY HH24:MI:SS') "NOW" FROM DUAL;
NOW
-------------------
02-16-2019 04:39:00
SQL> SELECT SYSDATE FROM DUAL;
SYSDATE
---------
16-FEB-19 Men i MySQL:
mysql> SELECT SYSDATE() FROM DUAL;
+---------------------+
| SYSDATE() |
+---------------------+
| 2019-02-15 20:37:36 |
+---------------------+
1 row in set (0.00 sec) Hvis du vil formatere datoen, har MySQL en DATE_FORMAT() funktion.
Du kan tjekke MySQL Dato and Time-dokumentationen for mere info.
TO_DATE
Oracles TO_DATE-ækvivalent i MySQL er STR_TO_DATE()-funktionen.
Den er næsten identisk med den i Oracle:den returnerer datatypen DATE, mens den i MySQL returnerer datatypen DATETIME.
Oracle:
SQL> SELECT TO_DATE ('20190218121212','yyyymmddhh24miss') as "NOW" FROM DUAL;
NOW
-------------------------
18-FEB-19 MySQL:
mysql> SELECT STR_TO_DATE('2019-02-18 12:12:12','%Y-%m-%d %H:%i:%s') as "NOW" FROM DUAL;
+---------------------+
| NOW |
+---------------------+
| 2019-02-18 12:12:12 |
+---------------------+
1 row in set (0.00 sec) SYNONYM
I MySQL er der ingen sådan støtte eller nogen ækvivalens for SYNONYM i Oracle.
Et muligt alternativ kan være muligt med MySQL er at bruge VIEW.
Selvom SYNONYM kan bruges til at oprette et alias for en ekstern tabel,
f.eks.
CREATE PUBLIC SYNONYM emp_table FOR [email protected] I MySQL kan du drage fordel af at bruge FEDERATED storage-motor.
f.eks.
CREATE TABLE hr_employees (
id INT(20) NOT NULL AUTO_INCREMENT,
name VARCHAR(32) NOT NULL DEFAULT '',
other INT(20) NOT NULL DEFAULT '0',
PRIMARY KEY (id),
INDEX name (name),
INDEX other_key (other)
)
ENGINE=FEDERATED
DEFAULT CHARSET=utf8mb4
CONNECTION='mysql://[email protected]_host:9306/federated/test_table'; Eller du kan forenkle processen med CREATE SERVER syntaks, så når du opretter en tabel, der fungerer som dit SYNONYM for at få adgang til en ekstern tabel, bliver det lettere. Se dokumentationen for mere information om dette.
Opførsel af tom streng og NULL
Bemærk, at i Percona Server / MySQL er tom streng ikke NULL, mens Oracle behandler tom streng som nulværdier.
I Oracle:
SQL> SELECT CASE WHEN '' IS NULL THEN 'Yes' ELSE 'No' END AS "Null Eval" FROM dual;
Nul
---
Yes I MySQL:
mysql> SELECT CASE WHEN '' IS NULL THEN 'Yes' ELSE 'No' END AS "Null Eval" FROM dual;
+-----------+
| Null Eval |
+-----------+
| No |
+-----------+
1 row in set (0.00 sec) Sekvenser
I MySQL er der ingen nøjagtig samme tilgang til, hvad Oracle gør for SEQUENCE.
Selvom der er nogle indlæg, der simulerer funktionaliteten af denne fremgangsmåde, kan du måske prøve at få den næste nøgle ved hjælp af LAST_INSERT_ID(), så længe din tabels klyngeindeks, PRIMARY KEY, er defineret med <
Tegnstrengfunktioner
I modsætning til Oracle har MySQL / Percona Server en håndfuld strengfunktioner, men ikke så mange nyttige funktioner indbygget i databasen.
Det ville være for langt at diskutere det her én for én, men du kan tjekke dokumentationen fra MySQL og sammenligne dette med Oracles strengfunktioner.
DML-erklæringer
Indsæt/opdater/slet udsagn fra Oracle stemmer overens i MySQL.
Oracles INSERT ALL/INSERT FIRST er ikke understøttet i MySQL.
Ellers skal du angive dine MySQL-forespørgsler én efter én.
f.eks.
I Oracle:
SQL> INSERT ALL
INTO CUSTOMERS (customer_id, customer_name, city) VALUES (1000, 'Jase Alagaban', 'Davao City')
INTO CUSTOMERS (customer_id, customer_name, city) VALUES (2000, 'Maximus Aleksandre Namuag', 'Davao City')
SELECT * FROM dual;
2 rows created. 2 rækker oprettet.
Men i MySQL skal du køre indsættelsen en ad gangen:
mysql> INSERT INTO CUSTOMERS (customer_id, customer_name, city) VALUES (1000, 'Jase Alagaban', 'Davao City');
Query OK, 1 row affected (0.02 sec)
mysql> INSERT INTO CUSTOMERS (customer_id, customer_name, city) VALUES (2000, 'Maximus Aleksandre Namuag', 'Davao City');
Query OK, 1 row affected (0.00 sec) INSERT ALL/INSERT FIRST kan ikke sammenlignes med, hvordan det bruges i Oracle, hvor du kan drage fordel af betingelserne ved at tilføje et NÅR nøgleord i din syntaks; der er ingen tilsvarende mulighed i MySQL / Percona Server i dette tilfælde.
Derfor er din alternative løsning på dette at bruge procedurer.
Ydre forbinder "+"-symbol
I Oracle er det ikke understøttet at bruge +-operatoren til venstre og højre joinforbindelse i øjeblikket i MySQL, da +-operatoren kun bruges til aritmetiske beslutninger.
Derfor, hvis du har + operator i dine eksisterende Oracle SQL-sætninger, skal du erstatte denne med LEFT JOIN eller RIGHT JOIN.
Du vil måske tjekke den officielle dokumentation for "Outer Join Simplification" af MySQL.
START MED..OPSLUT VED
Oracle bruger START WITH..CONNECT BY til hierarkiske forespørgsler.
Startende med MySQL / Percona 8.0, er der understøttelse af generering af hierarkiske dataresultater, som bruger modeller som f.eks. adjacency list eller indlejrede sæt modeller. Dette kaldes Common Table Expressions (CTE) i MySQL.
I lighed med PostgreSQL bruger MySQL WITH RECURSIVE syntaks for hierarkiske forespørgsler, så oversæt CONNECT BY sætning til MED RECURSIVE erklæring.
Tjek nedenfor om, hvordan det adskiller sig fra ORACLE og i MySQL / Percona Server.
I Oracle:
SELECT cp.id, cp.title, CONCAT(c2.title, ' > ' || cp.title) as path
FROM category cp INNER JOIN category c2
ON cp.parent_id = c2.id
WHERE cp.parent_id IS NOT NULL
START WITH cp.id >= 1
CONNECT BY NOCYCLE PRIOR c2.id=cp.parent_id; Og i MySQL:
WITH RECURSIVE category_path (id, title, path) AS
(
SELECT id, title, title as path
FROM category
WHERE parent_id IS NULL
UNION ALL
SELECT c.id, c.title, CONCAT(cp.path, ' > ', c.title)
FROM category_path AS cp JOIN category AS c
ON cp.id = c.parent_id
)
SELECT * FROM category_path
ORDER BY path; PL/SQL i MySQL/Percona?
MySQL / Percona RDBMS har en anden tilgang end Oracles PL/SQL.
MySQL bruger lagrede procedurer eller lagrede funktioner, som ligner PL/SQL og syntaks ved hjælp af BEGIN..END syntaks.
Oracles PL/SQL kompileres før udførelse, når den indlæses på serveren, mens MySQL kompileres og gemmes i cachen, når den startes.
Du ønsker måske at tjekke denne dokumentation som en referencevejledning til at konvertere din PL/SQL til MySQL.
Migreringsværktøjer
Jeg undersøgte nogle værktøjer, der kunne være en de facto-standard for migrering, men jeg kunne ikke finde et godt svar.
Jeg fandt dog sqlines, og det ser simpelt, men lovende ud.
Selvom jeg ikke dykkede dybt ned i det, tilbyder hjemmesiden en håndfuld indsigt, som kan hjælpe dig med at migrere fra Oracle til MySQL/Percona Server. Der er også betalte værktøjer som dette og dette.
Jeg har også søgt gennem github, men fandt intet meget mere tiltalende som en løsning på problemet. Derfor, hvis du sigter efter at migrere fra Oracle og til Amazon, har de AWS Schema Conversion Tool, som migrering fra Oracle til MySQL understøttes til.
Overordnet set er grunden til, at migrering ikke er en nem ting at gøre, primært fordi Oracle RDBMS er sådan et udyr med masser af funktioner, som Percona Server / MySQL eller MariaDB RDBMS stadig ikke har.
Under alle omstændigheder, hvis du finder eller kender til værktøjer, som du finder nyttige og gavnlige til at migrere fra Oracle til MySQL / Percona Server, bedes du efterlade en kommentar på denne blog!
Test
Som en del af din migrationsplan er test en vital opgave, der spiller en meget vigtig rolle og påvirker din beslutning med hensyn til migrering.
Værktøjet dbdeployer (en port af MySQL Sandbox) er et meget nyttigt værktøj, som du kan drage fordel af. Dette er ret nemt for dig at prøve forskellige tilgange og sparer dig tid, i stedet for at sætte hele stakken op, hvis dit formål er at prøve at teste RDBMS-platformen først.
For at teste dine SQL-lagrede rutiner (funktioner eller procedurer), triggere, hændelser, foreslår jeg, at du bruger disse værktøjer mytap eller Googles Unit Testing Framework.
Percona tilbyder også en række værktøjer, der er tilgængelige til download på deres hjemmeside. Tjek Percona Toolkit her. Du kan vælge værktøjerne efter dine behov, især til test- og produktionsbrugsopgaver.
Samlet set er de ting, du skal huske på som dine retningslinjer, når du laver en test for din MySQL-server:
- Efter din installation skal du overveje at foretage nogle justeringer. Tjek denne Percona-blog for at få hjælp.
- Udfør nogle benchmarks og stressbelastningstest for din konfigurationsopsætning på din nuværende node. Tjek mysqlslap og sysbench, som kan hjælpe dig med dette. Tjek også vores blog "Sådan benchmarker du MySQL &MariaDB's ydeevne ved hjælp af SysBench".
- Tjek dine DDL'er, om de er korrekt defineret, såsom datatyper, begrænsninger, klyngede og sekundære indekser eller partitioner, hvis du har nogen.
- Tjek din DML, især hvis syntaksen er korrekt og gemmer dataene korrekt som forventet.
- Tjek dine gemte rutiner, hændelser, trigger for at sikre, at de kører/returnerer de forventede resultater.
- Bekræft, at dine forespørgsler er effektive. Jeg foreslår, at du drager fordel af open source-værktøjer eller prøver vores ClusterControl-produkt. Det tilbyder overvågning/observation især af din MySQL / Percona Server. Du kan bruge ClusterControl her til at overvåge dine forespørgsler og dens forespørgselsplan for at sikre, at de er effektive.