Att migrera från Oracle till MySQL/Percona Server är inte en trivial uppgift. Även om det blir lättare, särskilt med ankomsten av MySQL 8.0 och Percona tillkännagav Percona Server för MySQL 8.0 GA. Förutom att planera för din migrering från Oracle till Percona Server, måste du se till att du förstår syftet och funktionen för varför det måste vara Percona Server.
Den här bloggen kommer att fokusera på migrering från Oracle till Percona Server som dess specifika måldatabas. Det finns en sida på Oracles webbplats om SQL Developer Supplementary Information for MySQL Migrations som kan användas som referens för den planerade migreringen. Den här bloggen kommer inte att täcka den övergripande migrationsprocessen, eftersom det är en lång process. Men det kommer förhoppningsvis att ge tillräckligt med bakgrundsinformation för att fungera som en guide för din migreringsprocess.
Eftersom Percona Server är en gaffel av MySQL, finns nästan alla funktioner som kommer med i MySQL i Percona Server. Så alla hänvisningar till MySQL här är också tillämpliga på Percona Server. Vi har tidigare bloggat om att migrera Oracle Database till PostgreSQL. Jag ska återigen upprepa skälen till varför man skulle överväga att migrera från Oracle till ett RDBMS med öppen källkod som PostgreSQL eller Percona Server/MySQL/MariaDB.
- Kostnad:Som du kanske vet är kostnaden för Oracle-licensen mycket dyr och det tillkommer extra kostnader för vissa funktioner som partitionering och hög tillgänglighet. Så överlag är det väldigt dyrt.
- Flexibel licensiering med öppen källkod och enkel tillgänglighet från offentliga molnleverantörer som AWS.
- Dra nytta av tillägg med öppen källkod för att förbättra prestandan.
Planerings- och utvecklingsstrategi
Migrering från Oracle till Percona Server 8.0 kan vara jobbigt eftersom det finns många nyckelfaktorer som måste beaktas och åtgärdas. Till exempel kan Oracle köras på en Windows Server-maskin men Percona Server stöder inte Windows. Även om du kan kompilera det för Windows, erbjuder Percona själv inget stöd för Windows. Du måste också identifiera dina databasarkitekturkrav, eftersom Percona Server inte är designad för OLAP (Online Analytical Processing) eller datalagringsapplikationer. Percona Server/MySQL RDBMS passar perfekt för OLTP (Online Transaction Processing).
Genom att identifiera nyckelaspekten av din databasarkitektur, till exempel om din nuvarande Oracle-arkitektur implementerar MAA (Maximum Available Architecture) med Data Guard ++ Oracle RAC (Real Application Cluster), bör du bestämma dess likvärdighet i Percona Server. Det finns inget rakt svar på detta inom MySQL/Percona Server. Du kan dock välja mellan en synkron replikering, en asynkron replikering (Percona XtraDB Cluster finns fortfarande på version 5.7.x) eller med gruppreplikering. Sedan finns det flera alternativ som du kan implementera för din egen högtillgänglighetslösning. Till exempel (för att nämna några) genom att använda Corosync/Pacemaker/DRBD/Linux-stack, eller använda MHA (MySQL High Availability), eller använda Keepalived/HaProxy/ProxySQL-stack, eller helt enkelt lita på ClusterControl som stöder Keepalved, HaProxy, ProxySQL, Garbd och Maxscale för dina lösningar med hög tillgänglighet.
Å andra sidan är frågan du också måste överväga som en del av planen "Hur kommer Percona att tillhandahålla support och vem hjälper oss när Percona Server själv stöter på en bugg eller hur hög är brådskan när vi behöver hjälp?". En sak att också tänka på är budget, om syftet med migrering från företagsdatabas till ett RDBMS med öppen källkod beror på kostnadsbesparingar.
Det finns olika alternativ från migrationsplanering till de saker du behöver göra som en del av din utvecklingsstrategi. Sådana alternativ inkluderar kontakt med experter inom MySQL/Percona Server-området och det inkluderar oss här på Severalnines. Det finns massor av MySQL-konsultföretag som kan hjälpa dig igenom detta eftersom migreringen från Oracle till MySQL kräver mycket expertis och kunnande inom MySQL Server-området. Detta bör inte begränsas till databasen utan det bör täcka expertis inom skalbarhet, redundans, säkerhetskopiering, hög tillgänglighet, säkerhet, övervakning/observerbarhet, återställning och engagemang i verksamhetskritiska system. Sammantaget bör den ha en förståelse för din arkitektoniska insikt utan att avslöja konfidentialitet för dina data.
Utvärdering eller preliminär kontroll
Säkerhetskopiering av dina data inklusive konfigurationer eller installationsfiler, kärnjusteringar, automatiseringsskript ska inte lämnas i glömska. Det är en självklar uppgift, men innan du migrerar, säkra alltid allt först, särskilt när du flyttar till en annan plattform.
Du måste också bedöma att dina applikationer följer de uppdaterade programvarukonstruktionskonventionerna och se till att de är plattformsoberoende. Dessa metoder kan vara till din fördel, särskilt när du flyttar till en annan databasplattform, som Percona Server för MySQL.
Notera att operativsystemet som Percona Server kräver kan vara en show-stopper om din applikation och databas körs på en Windows Server och applikationen är Windows-beroende; då kan det här bli mycket jobb! Kom alltid ihåg att Percona Server är på en annan plattform:perfektion kanske inte garanteras men kan uppnås tillräckligt nära.
Slutligen, se till att den riktade hårdvaran är designad för att fungera genomförbart med Perconas serverkrav eller att den åtminstone är buggfri (se här). Du kan överväga att stresstesta först med Percona Server innan du på ett tillförlitligt sätt flyttar bort din Oracle-databas.
Vad du bör veta
Det är värt att notera att i Percona Server / MySQL kan du skapa flera databaser medan Oracle inte kommer med samma funktionalitet som MySQL.
I MySQL är ett schema rent fysiskt synonymt med en databas. Du kan ersätta nyckelordet SCHEMA istället för DATABASE i MySQL SQL-syntax, till exempel genom att använda CREATE SCHEMA istället för CREATE DATABASE; medan Oracle har en distinktion av detta. Ett schema representerar bara en del av en databas:tabellerna och andra objekt som ägs av en enda användare. Normalt finns det en en-till-en-relation mellan instansen och databasen.
Till exempel, i en replikeringskonfiguration motsvarande i Oracle (t.ex. Real Application Clusters eller RAC), har du dina flera instanser åtkomst till en enda databas. Detta låter dig starta Oracle på flera servrar, men alla får åtkomst till samma data. Men i MySQL kan du tillåta åtkomst till flera databaser från dina flera instanser och kan till och med filtrera bort vilka databaser/schema du kan replikera till en MySQL-nod.
Med hänvisning från en av våra tidigare bloggar gäller samma princip när man talar om att konvertera din databas med tillgängliga verktyg som finns på internet.
Det finns inget sådant verktyg som till 100 % kan konvertera Oracle-databas till Percona Server / MySQL; en del av det kommer att vara manuellt arbete.
Kolla in följande avsnitt för saker som du måste vara medveten om när det gäller migrering och verifiering av det logiska SQL-resultatet.
Datatypmappning
MySQL / Percona Server har ett antal datatyper som är nästan samma som Oracle men inte lika rika jämfört med Oracle. Men sedan ankomsten av 5.7.8-versionen av MySQL, har stöd för en inbyggd JSON-datatyp.
Nedan är dess ekvivalenta representation av datatyp (tabellrepresentation är hämtad härifrån):
| Oracle | MySQL | |||
|---|---|---|---|---|
| 1 | BFILE | Pekare till binär fil, ⇐ 4G | VARCHAR(255) | |
| 2 | BINARY_FLOAT | 32-bitars flyttal | FLYTTA | |
| 3 | BINARY_DOUBLE | 64-bitars flyttal | DUBBLA | |
| 4 | BLOB | Binärt stort objekt, ⇐ 4G | LONGBLOB | |
| 5 | CHAR(n), CHARACTER(n) | sträng med fast längd, 1 ⇐ n ⇐ 255 | CHAR(n), CHARACTER(n) | |
| 6 | CHAR(n), CHARACTER(n) | Sträng med fast längd, 256 ⇐ n ⇐ 2000 | VARCHAR(n) | |
| 7 | CLOB | Tecken stort objekt, ⇐ 4G | LONGTEXT | |
| 8 | DATE | Datum och tid | DATETIME | |
| 9 | DECIMAL(p,s), DEC(p,s) | Fastpunktsnummer | DECIMAL(p,s), DEC(p,s) | |
| 10 | DUBBEL PRECISION | Flertal | DUBBEL PRECISION | |
| 11 | FLYTTA(p) | Flertal | DUBBLA | |
| 12 | INTEGER, INT | 38 siffror heltal | INT | DECIMAL(38) |
| 13 | INTERVALL ÅR(p) TILL MÅNAD | Datumintervall | VARCHAR(30) | |
| 14 | INTERVALL DAG(p) TILL SEKUND(AR) | Dag och tidsintervall | VARCHAR(30) | |
| 15 | LÅNG | Teckendata, ⇐ 2G | LONGTEXT | |
| 16 | LONG RAW | Binära data, ⇐ 2G | LONGBLOB | |
| 17 | NCHAR(n) | UTF-8-sträng med fast längd, 1 ⇐ n ⇐ 255 | NCHAR(n) | |
| 18 | NCHAR(n) | UTF-8-sträng med fast längd, 256 ⇐ n ⇐ 2000 | NVARCHAR(n) | |
| 19 | NCHAR VARIERANDE(n) | UTF-8-sträng med varierande längd, 1 ⇐ n ⇐ 4000 | NCHAR VARIANDE(n) | |
| 20 | NCLOB | Unicode-sträng med variabel längd, ⇐ 4G | NVARCHAR(max) | |
| 21 | NUMBER(p,0), NUMBER(p) | 8-bitars heltal, 1 <=p <3 | TINYINT | (0 till 255) |
| 16-bitars heltal, 3 <=p <5 | SMALLINT | |||
| 32-bitars heltal, 5 <=p <9 | INT | |||
| 64-bitars heltal, 9 <=p <19 | STORT | |||
| Fastpunktsnummer, 19 <=p <=38 | DECIMAL(p) | |||
| 22 | ANTAL(p,s) | Fastpunktsnummer, s> 0 | DECIMAL(p,s) | |
| 23 | NUMBER, NUMBER(*) | Flertal | DUBBLA | |
| 24 | NUMERISK(p,s) | Fastpunktsnummer | NUMERIC(p,s) | |
| 25 | NVARCHAR2(n) | UTF-8-sträng med variabel längd, 1 ⇐ n ⇐ 4000 | NVARCHAR(n) | |
| 26 | RAW(n) | Binär sträng med variabel längd, 1 ⇐ n ⇐ 255 | BINÄR(n) | |
| 27 | RAW(n) | Binär sträng med variabel längd, 256 ⇐ n ⇐ 2000 | VARBINÄR(n) | |
| 28 | VERKLIG | Flertal | DUBBLA | |
| 29 | ROWID | Fysisk radadress | CHAR(10) | |
| 30 | SMALLINT | 38 siffror heltal | DECIMAL(38) | |
| 31 | TIMESTAMP(p) | Datum och tid med bråkdel | DATETIME(p) | |
| 32 | TIDSSTÄMPEL(p) MED TIDZON | Datum och tid med bråktal och tidszon | DATETIME(p)  | |
| 33 | UROWID(n) | Logiska radadresser, 1 ⇐ n ⇐ 4000 | VARCHAR(n) | |
| 34 | VARCHAR(n) | Snöre med variabel längd, 1 ⇐ n ⇐ 4000 | VARCHAR(n) | |
| 35 | VARCHAR2(n) | Snöre med variabel längd, 1 ⇐ n ⇐ 4000 | VARCHAR(n) | |
| 36 | XMLTYPE | XML-data | LONGTEXT | |
Datatypsattribut och alternativ:
| Oracle | MySQL |
| BYTE och CHAR kolumnstorlek semantik | Storlek är alltid i tecken |
Transaktioner
Percona Server använder XtraDB (en förbättrad version av InnoDB) som sin primära lagringsmotor för att hantera transaktionsdata; även om olika lagringsmotorer kan vara ett alternativt val för att hantera transaktioner som TokuDB (utfasad) och MyRocks lagringsmotorer.
Även om det finns fördelar och fördelar med att använda eller utforska MyRocks med XtraDB, är den senare mer robust och de facto lagringsmotor som Percona Server använder och den är aktiverad som standard, så vi kommer att använda denna lagringsmotor som grund för migrering med avseende på till transaktioner.
Som standard har Percona Server / MySQL autocommit-variabel inställd på ON, vilket innebär att du explicit måste hantera transaktionssatser för att dra fördel av ROLLBACK för att ignorera ändringar eller utnyttja SAVEPOINT.
Det är i princip samma koncept som Oracle använder när det gäller commit, rollbacks och savepoints.
För explicita transaktioner betyder detta att du måste använda START TRANSACTION/BEGIN;
I annat fall, om du måste inaktivera autocommit, måste du uttryckligen KOMMITTIG hela tiden för dina uttalanden som kräver ändringar av dina data.
Dubbel tabell
MySQL har den dubbla kompatibiliteten med Oracle som är avsedd för kompatibilitet av databaser med en dummy-tabell, nämligen DUAL.
Detta passar Oracles användning av DUAL så eventuella befintliga uttalanden i din applikation som använder DUAL kanske inte kräver några ändringar vid migrering till Percona Server.
Oracle FROM-satsen är obligatorisk för varje SELECT-sats, så Oracle-databasen använder DUAL-tabell för SELECT-sats där ett tabellnamn inte krävs.
I MySQL är FROM-satsen inte obligatorisk så DUAL-tabellen är inte nödvändig. DUAL-tabellen fungerar dock inte exakt på samma sätt som den gör för Oracle, men för enkla SELECT i Percona Server är det bra.
Se följande exempel nedan:
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:00Men 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)Obs:DESC DUAL syntax fungerar inte i MySQL och resultaten skiljer sig också eftersom CURRENT_TIMESTAMP (använder datatyp TIMESTAMP) i MySQL inte inkluderar tidszonen.
SYSDATE
Oracles SYSDATE-funktion är nästan densamma i MySQL.
MySQL returnerar datum och tid och är en funktion som kräver () (stäng och öppen parentes utan några argument som krävs. För att demonstrera detta nedan, här är Oracle och MySQL om hur man använder SYSDATE.
I Oracle returnerar du med vanlig SYSDATE bara dagens datum utan tid. Men för att få tid och datum, använd TO_CHAR för att konvertera datum och tid till önskat format; I MySQL kanske du inte behöver det för att få datum och tid eftersom det returnerar båda.
Se exempel nedan.
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-19Men i MySQL:
mysql> SELECT SYSDATE() FROM DUAL;
+---------------------+
| SYSDATE() |
+---------------------+
| 2019-02-15 20:37:36 |
+---------------------+
1 row in set (0.00 sec)Om du vill formatera datumet har MySQL en DATE_FORMAT() funktion.
Du kan kontrollera MySQL-dokumentationen för datum och tid för mer information.
TO_DATE
Oracles TO_DATE-motsvarighet i MySQL är STR_TO_DATE()-funktionen.
Den är nästan identisk med den i Oracle:den returnerar datatypen DATE, medan den i MySQL returnerar datatypen DATETIME.
Oracle:
SQL> SELECT TO_DATE ('20190218121212','yyyymmddhh24miss') as "NOW" FROM DUAL;
NOW
-------------------------
18-FEB-19MySQL:
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 finns det inget sådant stöd eller någon likvärdighet för SYNONYM i Oracle.
Ett möjligt alternativ kan vara möjligt med MySQL är att använda VIEW.
Även om SYNONYM kan användas för att skapa ett alias för en fjärrtabell,
t.ex.
CREATE PUBLIC SYNONYM emp_table FOR [email protected]I MySQL kan du dra fördel av att använda FEDERATED lagringsmotor.
t.ex.
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 så kan du förenkla processen med CREATE SERVER syntax, så att när du skapar en tabell som fungerar som din SYNONYM för åtkomst till en fjärrtabell, blir det enklare. Se dokumentationen för mer information om detta.
Beteende av tom sträng och NULL
Observera att i Percona Server / MySQL är tom sträng inte NULL medan Oracle behandlar tom sträng som nollvärden.
I Oracle:
SQL> SELECT CASE WHEN '' IS NULL THEN 'Yes' ELSE 'No' END AS "Null Eval" FROM dual;
Nul
---
YesI 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 finns det ingen exakt samma metod för vad Oracle gör för SEQUENCE.
Även om det finns några inlägg som simulerar funktionen hos detta tillvägagångssätt, kanske du kan försöka få nästa nyckel med LAST_INSERT_ID() så länge som din tabells klustrade index, PRIMARY KEY, är definierat med <
Teckensträngsfunktioner
Till skillnad från Oracle har MySQL / Percona Server en handfull strängfunktioner men inte lika många användbara funktioner inbyggda i databasen.
Det skulle vara för långt att diskutera det här en i taget, men du kan kontrollera dokumentationen från MySQL och jämföra detta med Oracles strängfunktioner.
DML-uttalanden
Infoga/Uppdatera/Ta bort uttalanden från Oracle är kongruenta i MySQL.
Oracles INSERT ALL/INSERT FIRST stöds inte i MySQL.
Annars måste du ange dina MySQL-frågor en i taget.
t.ex.
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 rader skapade.
Men i MySQL måste du köra infogningen en i taget:
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 inte jämföras med hur det används i Oracle, där du kan dra fördel av villkoren genom att lägga till ett WHEN-nyckelord i din syntax; det finns inget motsvarande alternativ i MySQL / Percona Server i det här fallet.
Därför är din alternativa lösning på detta att använda procedurer.
Yttre sammanfogar "+"-symbol
I Oracle stöds för närvarande inte att använda +-operator för vänster- och högerkopplingar i MySQL eftersom +-operatorn endast används för aritmetiska beslut.
Därför, om du har + operator i dina befintliga Oracle SQL-satser, måste du ersätta denna med LEFT JOIN eller RIGHT JOIN.
Du kanske vill kontrollera den officiella dokumentationen för "Outer Join Simplification" av MySQL.
BÖRJA MED..KOPPLA VID
Oracle använder START WITH..CONNECT BY för hierarkiska frågor.
Från och med MySQL / Percona 8.0 finns det stöd för att generera hierarkiska dataresultat som använder modeller som närliggande list eller kapslade uppsättningsmodeller. Detta kallas Common Table Expressions (CTE) i MySQL.
I likhet med PostgreSQL använder MySQL WITH RECURSIVE syntax för hierarkiska frågor så översätt CONNECT BY uttalande till WITH RECURSIVE uttalande.
Kolla nedan om hur det skiljer sig från ORACLE och 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; Och 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 ett annat tillvägagångssätt än Oracles PL/SQL.
MySQL använder lagrade procedurer eller lagrade funktioner, vilket liknar PL/SQL och syntax med BEGIN..END syntax.
Oracles PL/SQL kompileras före körning när den laddas in i servern, medan MySQL kompileras och lagras i cachen när den anropas.
Du kanske vill kolla in den här dokumentationen som en referensguide för att konvertera din PL/SQL till MySQL.
Migreringsverktyg
Jag gjorde en del efterforskningar efter alla verktyg som skulle kunna vara en de facto-standard för migrering men jag kunde inte hitta ett bra svar.
Men jag hittade sqlines och det ser enkelt men lovande ut.
Även om jag inte fördjupade mig i det, erbjuder webbplatsen en handfull insikter som kan hjälpa dig att migrera från Oracle till MySQL/Percona Server. Det finns också betalverktyg som detta och det här.
Jag har också sökt igenom github men hittat inget mycket mer tilltalande som en lösning på problemet. Därför, om du siktar på att migrera från Oracle och till Amazon, har de AWS Schema Conversion Tool för vilket migrering från Oracle till MySQL stöds.
Sammantaget är anledningen till att migrering inte är en lätt sak att göra främst för att Oracle RDBMS är en sådan best med massor av funktioner som Percona Server / MySQL eller MariaDB RDBMS fortfarande inte har.
Hur som helst, om du hittar eller känner till några verktyg som du tycker är användbara och fördelaktiga för att migrera från Oracle till MySQL / Percona Server, vänligen lämna en kommentar på den här bloggen!
Testning
Som en del av din migreringsplan är testning en viktig uppgift som spelar en mycket viktig roll och som påverkar ditt beslut om migrering.
Verktyget dbdeployer (en port av MySQL Sandbox) är ett mycket användbart verktyg som du kan dra nytta av. Det här är ganska enkelt för dig att testa olika tillvägagångssätt och sparar tid, snarare än att ställa in hela stacken om ditt syfte är att försöka testa RDBMS-plattformen först.
För att testa dina SQL-lagrade rutiner (funktioner eller procedurer), triggers, händelser, föreslår jag att du använder dessa verktyg mytap eller Googles enhetstestningsram.
Percona erbjuder också ett antal verktyg som finns att ladda ner på deras hemsida. Kolla in Percona Toolkit här. Du kan välja verktygen efter dina behov, särskilt för test- och produktionsuppgifter.
Sammantaget är saker som du måste ha i åtanke som dina riktlinjer när du gör ett test för din MySQL-server:
- Efter installationen måste du överväga att göra lite justering. Kolla in den här Percona-bloggen för hjälp.
- Gör några riktmärken och stressbelastningstester för din konfigurationskonfiguration på din nuvarande nod. Kolla in mysqlslap och sysbench som kan hjälpa dig med detta. Kolla även in vår blogg "Hur man jämför prestanda för MySQL &MariaDB med SysBench".
- Kontrollera dina DDL:er om de är korrekt definierade såsom datatyper, begränsningar, klustrade och sekundära index eller partitioner, om du har några.
- Kontrollera din DML särskilt om syntaxen är korrekt och sparar data korrekt som förväntat.
- Kolla in dina lagrade rutiner, händelser, trigger för att säkerställa att de körs/returnerar de förväntade resultaten.
- Verifiera att dina sökfrågor fungerar. Jag föreslår att du drar fördel av verktyg med öppen källkod eller provar vår ClusterControl-produkt. Den erbjuder övervakning/observerbarhet speciellt av din MySQL/Percona-server. Du kan använda ClusterControl här för att övervaka dina frågor och dess frågeplan för att se till att de fungerar.