Migrace z Oracle na MySQL/Percona Server není triviální úkol. I když je to stále jednodušší, zejména s příchodem MySQL 8.0 a Percona oznámila Percona Server pro MySQL 8.0 GA. Kromě plánování migrace z Oracle na Percona Server se musíte ujistit, že rozumíte účelu a funkcím, proč to musí být Percona Server.
Tento blog se zaměří na migraci z Oracle na Percona Server jako specifickou cílovou databázi. Na webu Oracle je stránka o SQL Developer Supplementary Information for MySQL Migrations, kterou lze použít jako referenci pro plánovanou migraci. Tento blog nebude pokrývat celkový proces migrace, protože je to dlouhý proces. Doufejme však, že poskytne dostatek základních informací, které vám poslouží jako vodítko pro váš proces migrace.
Vzhledem k tomu, že Percona Server je fork MySQL, jsou v Percona Server přítomny téměř všechny funkce, které jsou součástí MySQL. Takže jakýkoli odkaz na MySQL zde je použitelný také pro Percona Server. Dříve jsme blogovali o migraci databáze Oracle na PostgreSQL. Znovu zopakuji důvody, proč by se dalo uvažovat o migraci z Oracle na open-source RDBMS, jako je PostgreSQL nebo Percona Server/MySQL/MariaDB.
- Cena:Jak možná víte, cena licence Oracle je velmi drahá a některé funkce, jako je dělení na oddíly a vysoká dostupnost, jsou navíc náklady. Celkově je to tedy velmi drahé.
- Flexibilní licencování open source a snadná dostupnost od poskytovatelů veřejného cloudu, jako je AWS.
- Využijte výhody open source doplňků ke zlepšení výkonu.
Strategie plánování a rozvoje
Migrace z Oracle na Percona Server 8.0 může být bolestivá, protože existuje mnoho klíčových faktorů, které je třeba zvážit a řešit. Oracle může například běžet na počítači se systémem Windows Server, ale Percona Server nepodporuje Windows. Přestože jej můžete zkompilovat pro Windows, Percona sama o sobě žádnou podporu pro Windows nenabízí. Musíte také určit své požadavky na architekturu databáze, protože Percona Server není navržen pro aplikace OLAP (Online Analytical Processing) nebo datové sklady. Percona Server/MySQL RDBMS se perfektně hodí pro OLTP (Online Transaction Processing).
Identifikace klíčového aspektu vaší databázové architektury, například pokud vaše současná architektura Oracle implementuje MAA (Maximum Available Architecture) s Data Guard ++ Oracle RAC (Real Application Cluster), měli byste určit její ekvivalent v Percona Server. V rámci serveru MySQL/Percona na to neexistuje žádná přímá odpověď. Můžete si však vybrat ze synchronní replikace, asynchronní replikace (Percona XtraDB Cluster je stále aktuálně ve verzi 5.7.x) nebo se skupinovou replikací. Pak existuje několik alternativ, které můžete implementovat pro své vlastní řešení s vysokou dostupností. Například (abychom jmenovali alespoň některé) pomocí zásobníku Corosync/Pacemaker/DRBD/Linux nebo pomocí MHA (MySQL High Availability) nebo pomocí zásobníku Keepalived/HaProxy/ProxySQL, nebo se jednoduše spolehnout na ClusterControl, který podporuje Keepalived, HaProxy, ProxySQL, Garbd a Maxscale pro vaše řešení s vysokou dostupností.
Na druhou stranu, otázka, kterou musíte v rámci plánu také zvážit, zní:„Jak nám Percona poskytne podporu a kdo nám pomůže, když Percona Server sám narazí na chybu nebo jak vysoká je naléhavost, když potřebujeme pomoc?“. Jedna věc, kterou je také třeba zvážit, je rozpočet, pokud účelem migrace z podnikové databáze na open-source RDBMS je snížení nákladů.
Existují různé možnosti od plánování migrace až po věci, které musíte udělat jako součást vaší rozvojové strategie. Mezi takové možnosti patří spolupráce s odborníky v oblasti serveru MySQL/Percona, což zahrnuje i nás zde v Somenines. Existuje mnoho konzultačních firem pro MySQL, které vám s tím mohou pomoci, protože migrace z Oracle na MySQL vyžaduje mnoho odborných znalostí a know-how v oblasti serveru MySQL. To by nemělo být omezeno na databázi, ale mělo by zahrnovat odborné znalosti v oblasti škálovatelnosti, redundance, zálohování, vysoké dostupnosti, zabezpečení, monitorování/pozorovatelnosti, obnovy a zapojení do kritických systémů. Celkově by měl rozumět vašemu architektonickému náhledu, aniž by odhalil důvěrnost vašich dat.
Posouzení nebo předběžná kontrola
Zálohování vašich dat včetně konfigurací nebo instalačních souborů, ladění jádra, automatizačních skriptů nesmí zůstat v zapomnění. Je to samozřejmý úkol, ale před migrací vždy nejprve vše zajistěte, zvláště když přecházíte na jinou platformu.
Musíte také posoudit, zda vaše aplikace dodržují aktuální konvence softwarového inženýrství, a zajistit, že jsou agnostické pro platformu. Tyto postupy mohou být pro vás přínosem zejména při přechodu na jinou databázovou platformu, jako je Percona Server pro MySQL.
Berte na vědomí, že operační systém, který Percona Server vyžaduje, může být překážkou, pokud vaše aplikace a databáze běží na Windows Serveru a aplikace je závislá na Windows; pak to může být hodně práce! Vždy mějte na paměti, že Percona Server je na jiné platformě:dokonalost nemusí být zaručena, ale lze ji dosáhnout dostatečně blízko.
Nakonec se ujistěte, že cílový hardware je navržen tak, aby vyhovoval požadavkům serveru Percona, nebo že je alespoň bez chyb (viz zde). Než se spolehlivě přesunete z databáze Oracle, můžete nejprve zvážit zátěžové testování s Percona Server.
Co byste měli vědět
Stojí za zmínku, že v Percona Server / MySQL můžete vytvořit více databází, zatímco Oracle nepřichází se stejnou funkčností jako MySQL.
V MySQL je schéma fyzicky synonymem pro databázi. V syntaxi MySQL SQL můžete nahradit klíčové slovo SCHEMA místo DATABASE, například pomocí CREATE SCHEMA místo CREATE DATABASE; zatímco Oracle má na to rozdíl. Schéma představuje pouze část databáze:tabulky a další objekty vlastněné jedním uživatelem. Normálně je mezi instancí a databází vztah jedna ku jedné.
Například v ekvivalentu nastavení replikace v Oracle (např. Real Application Clusters nebo RAC) máte více instancí přistupujících k jediné databázi. To vám umožní spustit Oracle na více serverech, ale všechny budou mít přístup ke stejným datům. V MySQL však můžete povolit přístup k více databázím z vašich více instancí a můžete dokonce odfiltrovat, které databáze/schéma můžete replikovat do uzlu MySQL.
Odkazujeme-li na jeden z našich předchozích blogů, stejný princip platí, když mluvíme o převodu databáze pomocí dostupných nástrojů dostupných na internetu.
Neexistuje žádný takový nástroj, který by dokázal 100% převést databázi Oracle na Percona Server / MySQL; něco z toho bude ruční práce.
V následujících částech najdete věci, kterých si musíte být vědomi, pokud jde o migraci a ověření logického výsledku SQL.
Mapování datových typů
MySQL / Percona Server má řadu datových typů, které jsou téměř stejné jako Oracle, ale nejsou tak bohaté ve srovnání s Oracle. Ale od příchodu verze 5.7.8 MySQL je podporován nativní datový typ JSON.
Níže je jeho ekvivalentní reprezentace datového typu (tabulková reprezentace je převzata odtud):
| Oracle | MySQL | |||
|---|---|---|---|---|
| 1 | BFILE | Ukazatel na binární soubor, ⇐ 4G | VARCHAR(255) | |
| 2 | BINARY_FLOAT | 32bitové číslo s plovoucí desetinnou čárkou | PLOVOUCÍ | |
| 3 | BINARY_DOUBLE | 64bitové číslo s plovoucí desetinnou čárkou | DVOJNÁSOBKA | |
| 4 | BLOB | Binární velký objekt, ⇐ 4G | LONGBLOB | |
| 5 | CHAR(n), CHARACTER(n) | Řetězec pevné délky, 1 ⇐ n ⇐ 255 | CHAR(n), CHARACTER(n) | |
| 6 | CHAR(n), CHARACTER(n) | Řetězec pevné délky, 256 ⇐ n ⇐ 2000 | VARCHAR(n) | |
| 7 | CLOB | Znak velký objekt, ⇐ 4G | LONGTEXT | |
| 8 | DATUM | Datum a čas | DATETIME | |
| 9 | DECIMAL(p,s), DEC(p,s) | Číslo s pevnou čárkou | DECIMAL(p,s), DEC(p,s) | |
| 10 | DVOJNÁSOBNÁ PŘESNOST | Číslo s plovoucí desetinnou čárkou | DVOJNÁSOBNÁ PŘESNOST | |
| 11 | FLOAT(p) | Číslo s plovoucí desetinnou čárkou | DVOJNÁSOBKA | |
| 12 | INTEGER, INT | 38místné celé číslo | INT | DECIMAL(38) |
| 13 | INTERVAL ROK(p) DO MĚSÍCE | Interval dat | VARCHAR(30) | |
| 14 | INTERVAL DEN(p) AŽ SEKUNDA(y) | Den a časový interval | VARCHAR(30) | |
| 15 | DLOUHÉ | Údaje o postavách, ⇐ 2G | LONGTEXT | |
| 16 | LONG RAW | Binární data, ⇐ 2G | LONGBLOB | |
| 17 | NCHAR(n) | Řetězec UTF-8 pevné délky, 1 ⇐ n ⇐ 255 | NCHAR(n) | |
| 18 | NCHAR(n) | Řetězec UTF-8 s pevnou délkou, 256 ⇐ n ⇐ 2000 | NVARCHAR(n) | |
| 19 | NCHAR VARYING(n) | Řetězec UTF-8 různé délky, 1 ⇐ n ⇐ 4000 | NCHAR VARYING(n) | |
| 20 | NCLOB | Řetězec Unicode s proměnnou délkou, ⇐ 4G | NVARCHAR(max) | |
| 21 | NUMBER(p,0), NUMBER(p) | 8bitové celé číslo, 1 <=p <3 | TINYINT | (0 až 255) |
| 16bitové celé číslo, 3 <=p <5 | SMALLINT | |||
| 32bitové celé číslo, 5 <=p <9 | INT | |||
| 64bitové celé číslo, 9 <=p <19 | VELKÝ | |||
| Číslo s pevnou čárkou, 19 <=p <=38 | DECIMAL(p) | |||
| 22 | NUMBER(p,s) | Číslo s pevnou čárkou, s> 0 | DECIMAL(p,s) | |
| 23 | ČÍSLO, ČÍSLO(*) | Číslo s plovoucí desetinnou čárkou | DVOJNÁSOBKA | |
| 24 | NUMERIC(p,s) | Číslo s pevnou čárkou | NUMERIC(p,s) | |
| 25 | NVARCHAR2(n) | Řetězec UTF-8 s proměnnou délkou, 1 ⇐ n ⇐ 4000 | NVARCHAR(n) | |
| 26 | RAW(n) | Binární řetězec s proměnnou délkou, 1 ⇐ n ⇐ 255 | BINARY(n) | |
| 27 | RAW(n) | Binární řetězec s proměnnou délkou, 256 ⇐ n ⇐ 2000 | VARBINARY(n) | |
| 28 | SKUTEČNÉ | Číslo s plovoucí desetinnou čárkou | DVOJNÁSOBKA | |
| 29 | ROWID | Fyzická adresa řádku | CHAR(10) | |
| 30 | SMALLINT | 38místné celé číslo | DECIMAL(38) | |
| 31 | TIMESTAMP(p) | Datum a čas se zlomkem | DATETIME(p) | |
| 32 | TIMESTAMP(p) S ČASOVÝM PÁSEM | Datum a čas se zlomkem a časovým pásmem | DATETIME(p)  | |
| 33 | UROWID(n) | Logické adresy řádků, 1 ⇐ n ⇐ 4000 | VARCHAR(n) | |
| 34 | VARCHAR(n) | Řetězec s proměnnou délkou, 1 ⇐ n ⇐ 4000 | VARCHAR(n) | |
| 35 | VARCHAR2(n) | Řetězec s proměnnou délkou, 1 ⇐ n ⇐ 4000 | VARCHAR(n) | |
| 36 | XMLTYPE | Data XML | LONGTEXT | |
Atributy a možnosti datových typů:
| Oracle | MySQL |
| Sémantika velikosti sloupců BYTE a CHAR | Velikost je vždy ve znacích |
Transakce
Percona Server používá XtraDB (vylepšenou verzi InnoDB) jako primární úložiště pro zpracování transakčních dat; ačkoli různé úložné moduly mohou být alternativní volbou pro zpracování transakcí, jako jsou úložné moduly TokuDB (zastaralé) a MyRocks.
I když používání nebo prozkoumávání MyRocks s XtraDB má své výhody a výhody, XtraDB je robustnější a de facto úložný engine, který Percona Server používá a je ve výchozím nastavení povolen, takže tento úložný modul použijeme jako základ pro migraci s ohledem na k transakcím.
Ve výchozím nastavení má Percona Server / MySQL proměnnou autocommit nastavenou na ON, což znamená, že musíte explicitně zpracovávat transakční příkazy, abyste mohli využít ROLLBACK pro ignorování změn nebo využití výhod používání SAVEPOINT.
Je to v podstatě stejný koncept, který Oracle používá, pokud jde o odevzdání, vrácení zpět a body uložení.
Pro explicitní transakce to znamená, že musíte použít START TRANSACTION/BEGIN;
V opačném případě, pokud musíte deaktivovat autocommit, musíte explicitně COMMIT po celou dobu pro vaše výpisy, které vyžadují změny vašich dat.
Duální stůl
MySQL má duální kompatibilitu s Oracle, která je určena pro kompatibilitu databází pomocí fiktivní tabulky, konkrétně DUAL.
To vyhovuje použití Oracle DUAL, takže jakékoli stávající příkazy ve vaší aplikaci, které používají DUAL, nemusí vyžadovat žádné změny při migraci na Percona Server.
Klauzule Oracle FROM je povinná pro každý příkaz SELECT, takže databáze Oracle používá pro příkaz SELECT DUAL tabulku, kde není vyžadován název tabulky.
V MySQL není klauzule FROM povinná, takže DUAL tabulka není nutná. Tabulka DUAL však nefunguje úplně stejně jako pro Oracle, ale pro jednoduché SELECT v Percona Server je to v pořádku.
Viz následující příklad níže:
V 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:00Ale v 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)Poznámka:DESC DUAL syntaxe nefunguje v MySQL a výsledky se také liší, protože CURRENT_TIMESTAMP (používá datový typ TIMESTAMP) v MySQL nezahrnuje časové pásmo.
SYSDATE
Funkce SYSDATE společnosti Oracle je v MySQL téměř stejná.
MySQL vrací datum a čas a je to funkce, která vyžaduje () (zavřená a otevřená závorka bez nutnosti argumentů. Abychom to demonstrovali níže, zde je Oracle a MySQL o použití SYSDATE.
V Oracle použití prostého SYSDATE pouze vrátí datum dne bez času. Chcete-li však získat čas a datum, použijte TO_CHAR k převodu data a času do požadovaného formátu; zatímco v MySQL jej možná nebudete potřebovat k získání data a času, protože vrací obojí.
Viz příklad níže.
V 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-19Ale v MySQL:
mysql> SELECT SYSDATE() FROM DUAL;
+---------------------+
| SYSDATE() |
+---------------------+
| 2019-02-15 20:37:36 |
+---------------------+
1 row in set (0.00 sec)Pokud chcete formátovat datum, MySQL má funkci DATE_FORMAT().
Další informace naleznete v dokumentaci data a času MySQL.
TO_DATE
Ekvivalentem TO_DATE od Oracle v MySQL je funkce STR_TO_DATE().
Je téměř identický s tím v Oracle:vrací datový typ DATE, zatímco v MySQL vrací datový typ 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
V MySQL neexistuje žádná taková podpora ani žádná rovnocennost pro SYNONYM v Oracle.
Možnou alternativou může být s MySQL použití VIEW.
Ačkoli SYNONYM lze použít k vytvoření aliasu vzdálené tabulky,
např.
CREATE PUBLIC SYNONYM emp_table FOR [email protected]V MySQL můžete využít výhod použití FEDERATED storage engine.
např.
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';Nebo můžete proces zjednodušit pomocí syntaxe CREATE SERVER, takže při vytváření tabulky fungující jako vaše SYNONYM pro přístup ke vzdálené tabulce bude jednodušší. Další informace naleznete v dokumentaci.
Chování prázdného řetězce a NULL
Vezměte na vědomí, že v Percona Server / MySQL není prázdný řetězec NULL, zatímco Oracle považuje prázdný řetězec za hodnoty null.
V Oracle:
SQL> SELECT CASE WHEN '' IS NULL THEN 'Yes' ELSE 'No' END AS "Null Eval" FROM dual;
Nul
---
YesV 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)Sekvence
V MySQL neexistuje přesně stejný přístup k tomu, co Oracle dělá pro SEQUENCE.
Ačkoli existují některé příspěvky, které simulují funkčnost tohoto přístupu, můžete se pokusit získat další klíč pomocí LAST_INSERT_ID(), pokud je seskupený index vaší tabulky, PRIMARY KEY, definován pomocí <<, chybí tam něco?>>
Funkce řetězce znaků
Na rozdíl od Oracle má MySQL / Percona Server několik řetězcových funkcí, ale ne tolik užitečných funkcí zabudovaných do databáze.
Bylo by příliš dlouhé rozebírat to zde jeden po druhém, ale můžete si prohlédnout dokumentaci z MySQL a porovnat to s funkcemi řetězců Oracle.
Prohlášení DML
Příkazy Insert/Update/Delete z Oracle jsou v MySQL shodné.
INSERT ALL/INSERT FIRST společnosti Oracle není podporován v MySQL.
Jinak byste museli své dotazy MySQL uvádět jeden po druhém.
např.
V 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.Byly vytvořeny 2 řádky.
Ale v MySQL musíte vložit spustit jeden po druhém:
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 se nedá srovnávat s tím, jak se používá v Oracle, kde můžete využít podmínky přidáním klíčového slova WHEN do své syntaxe; v tomto případě v MySQL / Percona Server není žádná ekvivalentní možnost.
Proto je vaším alternativním řešením použití procedur.
Vnější spojení symbolu „+“
V Oracle není použití operátoru + pro levé a pravé spojení v současnosti v MySQL podporováno, protože operátor + se používá pouze pro aritmetická rozhodnutí.
Pokud tedy máte ve svých stávajících příkazech Oracle SQL operátor +, musíte jej nahradit LEFT JOIN nebo RIGHT JOIN.
Možná budete chtít zkontrolovat oficiální dokumentaci pro "Zjednodušení vnějšího připojení" MySQL.
ZAČÍT S..CONNECT BY
Oracle používá START WITH..CONNECT BY pro hierarchické dotazy.
Počínaje MySQL / Percona 8.0 existuje podpora pro generování výsledků hierarchických dat, které využívají modely, jako je seznam sousedství nebo modely vnořených množin. To se v MySQL nazývá Common Table Expressions (CTE).
Podobně jako PostgreSQL používá MySQL S REKURSIVNÍM syntaxe pro hierarchické dotazy, takže přeložte CONNECT BY příkaz do S REKURSIVNÍM prohlášení.
Níže se podívejte, jak se liší od ORACLE a MySQL / Percona Server.
V 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; A v 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 v MySQL / Percona?
MySQL / Percona RDBMS má jiný přístup než Oracle PL/SQL.
MySQL používá uložené procedury nebo uložené funkce, které jsou podobné PL/SQL a syntaxi pomocí BEGIN..END syntaxe.
Oracle PL/SQL je kompilován před spuštěním, když je načten na server, zatímco MySQL je kompilován a uložen do mezipaměti, když je vyvolán.
Možná si budete chtít prohlédnout tuto dokumentaci jako referenční příručku pro převod vašeho PL/SQL na MySQL.
Nástroje pro migraci
Zkoumal jsem nějaké nástroje, které by mohly být de facto standardem pro migraci, ale nenašel jsem dobrou odpověď.
I když jsem našel sqlines a vypadá to jednoduše, ale slibně.
I když jsem se tím neponořil do hloubky, webová stránka nabízí několik postřehů, které by vám mohly pomoci s migrací z Oracle na MySQL/Percona Server. Existují také placené nástroje, jako je tento a tento.
Také jsem hledal přes github, ale nenašel jsem nic mnohem přitažlivějšího jako řešení problému. Pokud se tedy chystáte migrovat z Oracle a na Amazon, mají AWS Schema Conversion Tool, pro který je podporována migrace z Oracle na MySQL.
Celkově důvod, proč není migrace jednoduchá věc, je hlavně ten, že Oracle RDBMS je takové zvíře se spoustou funkcí, které Percona Server / MySQL nebo MariaDB RDBMS stále nemají.
Každopádně pokud najdete nebo znáte nějaké nástroje, které považujete za užitečné a přínosné pro migraci z Oracle na MySQL / Percona Server, zanechte prosím komentář na tomto blogu!
Testování
V rámci vašeho plánu migrace je testování životně důležitým úkolem, který hraje velmi důležitou roli a ovlivňuje vaše rozhodnutí ohledně migrace.
Nástroj dbdeployer (port MySQL Sandbox) je velmi užitečný nástroj, který můžete využít. To je pro vás docela snadné vyzkoušet a otestovat různé přístupy a ušetří vám to čas, spíše než nastavování celého zásobníku, pokud je vaším účelem nejprve vyzkoušet a otestovat platformu RDBMS.
K testování vašich uložených rutin SQL (funkcí nebo procedur), spouštěčů, událostí vám doporučuji použít tyto nástroje mytap nebo Google Unit Testing Framework.
Percona také nabízí řadu nástrojů, které jsou k dispozici ke stažení na jejich webových stránkách. Pokladna Percona Toolkit zde. Můžete si vybrat nástroje podle svých potřeb, zejména pro úlohy testování a produkčního použití.
Celkově vzato, věci, které musíte mít na paměti jako pokyny při provádění testu serveru MySQL, jsou:
- Po instalaci je třeba zvážit provedení určitého doladění. Nápovědu najdete na tomto blogu Percona.
- Proveďte několik srovnávacích testů a zátěžových testů pro nastavení konfigurace na aktuálním uzlu. Podívejte se na mysqlslap a sysbench, které vám s tím mohou pomoci. Podívejte se také na náš blog „Jak srovnávat výkon MySQL a MariaDB pomocí SysBench“.
- Zkontrolujte, zda jsou vaše DDL správně definovány, jako jsou datové typy, omezení, seskupené a sekundární indexy nebo oddíly, pokud nějaké máte.
- Zkontrolujte svůj DML, zejména pokud je syntaxe správná a ukládá data správně podle očekávání.
- Podívejte se na své uložené rutiny, události a spouštěče, abyste se ujistili, že se spouští/vrací očekávané výsledky.
- Ověřte, zda jsou vaše spuštěné dotazy výkonné. Navrhuji, abyste využili nástroje s otevřeným zdrojovým kódem nebo vyzkoušeli náš produkt ClusterControl. Nabízí monitorování/pozorovatelnost zejména vašeho MySQL / Percona Serveru. Zde můžete použít ClusterControl ke sledování vašich dotazů a jejich plánu dotazů, abyste se ujistili, že jsou výkonné.