Мигрирането от Oracle към MySQL/Percona Server не е тривиална задача. Въпреки че става все по-лесно, особено с пристигането на MySQL 8.0 и Percona обяви Percona Server за MySQL 8.0 GA. Освен да планирате миграцията си от Oracle към Percona Server, трябва да сте сигурни, че разбирате целта и функционалността защо трябва да бъде Percona Server.
Този блог ще се фокусира върху мигрирането от Oracle към Percona Server като специфична целева база данни по избор. В уебсайта на Oracle има страница за допълнителна информация за SQL Developer за MySQL миграции, която може да се използва като справка за планираната миграция. Този блог няма да обхваща цялостния процес на миграция, тъй като това е дълъг процес. Но се надяваме, че ще предостави достатъчно основна информация, която да служи като ръководство за вашия процес на миграция.
Тъй като Percona Server е разклонение на MySQL, почти всички функции, които идват в MySQL, присъстват в Percona Server. Така че всяка справка на MySQL тук е приложима и за Percona Server. Преди това писахме в блогове за мигриране на Oracle Database към PostgreSQL. Ще повторя отново причините, поради които човек би помислил за мигриране от Oracle към RDBMS с отворен код като PostgreSQL или Percona Server/MySQL/MariaDB.
- Цена:Както може би знаете цената на лиценза на Oracle е много скъпа и има допълнителни разходи за някои функции като разделяне и висока наличност. Така че като цяло е много скъпо.
- Гъвкаво лицензиране с отворен код и лесна достъпност от публични доставчици на облак като AWS.
- Възползвайте се от добавките с отворен код, за да подобрите производителността.
Стратегия за планиране и развитие
Миграцията от Oracle към Percona Server 8.0 може да бъде мъка, тъй като има много ключови фактори, които трябва да бъдат разгледани и адресирани. Например Oracle може да работи на машина с Windows Server, но Percona Server не поддържа Windows. Въпреки че можете да го компилирате за Windows, самата Percona не предлага никаква поддръжка за Windows. Трябва също да идентифицирате изискванията за архитектура на базата данни, тъй като Percona Server не е проектиран за OLAP (онлайн аналитична обработка) или приложения за съхранение на данни. Percona Server/MySQL RDBMS са идеални за OLTP (онлайн обработка на транзакции).
Идентифицирайки ключовия аспект на архитектурата на вашата база данни, например ако текущата ви архитектура на Oracle прилага MAA (Максимално налична архитектура) с Data Guard ++ Oracle RAC (Real Application Cluster), трябва да определите нейната еквивалентност в Percona Server. Няма ясен отговор за това в MySQL/Percona Server. Въпреки това, можете да избирате между синхронна репликация, асинхронна репликация (Percona XtraDB Cluster все още е във версия 5.7.x) или с групова репликация. След това има множество алтернативи, които можете да приложите за вашето собствено решение с висока достъпност. Например (за да назовем няколко) с помощта на стека Corosync/Pacemaker/DRBD/Linux, или с помощта на MHA (MySQL High Availability), или чрез Keepalived/HaProxy/ProxySQL стека, или просто разчитайте на ClusterControl, който поддържа Keepalived, HaProxy, ProxySQL, Garbd и Maxscale за вашите решения с висока достъпност.
От друга страна, въпросът, който също трябва да вземете предвид като част от плана, е „Как Percona ще осигури поддръжка и кой ще ни помогне, когато самият Percona Server срещне бъг или колко голяма е спешността, когато имаме нужда от помощ?“. Едно нещо, което също трябва да имате предвид, е бюджетът, ако целта на миграцията от корпоративна база данни към RDBMS с отворен код е поради намаляване на разходите.
Има различни опции от планиране на миграцията до нещата, които трябва да направите като част от вашата стратегия за развитие. Такива опции включват ангажиране с експерти в областта на MySQL/Percona Server и това включва и нас тук в Severalnines. Има много MySQL консултантски фирми, които могат да ви помогнат през това, тъй като миграцията от Oracle към MySQL изисква много опит и ноу-хау в областта на MySQL Server. Това не трябва да се ограничава до базата данни, но трябва да обхваща експертен опит в мащабируемостта, резервирането, архивирането, високата наличност, сигурността, наблюдението/наблюдаемостта, възстановяването и ангажирането с критични за мисия системи. Като цяло трябва да има разбиране за вашата архитектурна проницателност, без да разкрива поверителността на вашите данни.
Оценка или предварителна проверка
Архивирането на вашите данни, включително конфигурации или файлове за настройка, настройки на ядрото, скриптове за автоматизация, няма да бъде оставено в забвение. Това е очевидна задача, но преди да мигрирате, винаги първо осигурявайте всичко, особено когато преминавате към друга платформа.
Трябва също да прецените дали вашите приложения следват актуалните конвенции за софтуерно инженерство и да се уверите, че са независими от платформата. Тези практики могат да бъдат от ваша полза, особено при преминаване към друга платформа за бази данни, като Percona Server за MySQL.
Обърнете внимание, че операционната система, която Percona Server изисква, може да бъде запушалка, ако вашето приложение и база данни работят на Windows Server и приложението зависи от Windows; тогава това може да бъде много работа! Винаги помнете, че Percona Server е на различна платформа:съвършенството може да не е гарантирано, но може да бъде постигнато достатъчно близо.
И накрая, уверете се, че целевият хардуер е проектиран да работи възможно с изискванията на сървъра на Percona или че е без грешки поне (вижте тук). Може да помислите първо за стрес тестване с Percona Server, преди надеждно да преместите своята база данни на Oracle.
Какво трябва да знаете
Струва си да се отбележи, че в Percona Server / MySQL можете да създавате множество бази данни, докато Oracle не се предлага със същата функционалност като MySQL.
В MySQL, физически, схемата е синоним на база данни. Можете да замените ключовата дума SCHEMA вместо DATABASE в MySQL SQL синтаксис, например като използвате CREATE SCHEMA вместо СЪЗДАВАНЕ НА БАЗА ДАННИ; докато Oracle има разлика в това. Схемата представлява само част от база данни:таблиците и други обекти, притежавани от един потребител. Обикновено има връзка едно към едно между екземпляра и базата данни.
Например, в еквивалентна настройка на репликация в Oracle (например реални клъстери от приложения или RAC), имате множество екземпляри, които имат достъп до една база данни. Това ви позволява да стартирате Oracle на множество сървъри, но всички имат достъп до едни и същи данни. Въпреки това, в MySQL можете да разрешите достъп до множество бази данни от множеството си екземпляри и дори да филтрирате кои бази данни/схема можете да репликирате в MySQL възел.
Позовавайки се на един от предишните ни блогове, същият принцип важи, когато говорим за конвертиране на вашата база данни с налични инструменти, намерени в интернет.
Няма такъв инструмент, който да конвертира 100% база данни на Oracle в Percona Server / MySQL; част от това ще бъде ръчна работа.
Разгледайте следните раздели за неща, които трябва да сте наясно, когато става въпрос за миграция и проверка на логическия SQL резултат.
Съпоставяне на типове данни
MySQL / Percona Server имат редица типове данни, които са почти същите като Oracle, но не са толкова богати в сравнение с Oracle. Но след пристигането на версията 5.7.8 на MySQL, поддържа роден тип данни JSON.
По-долу е неговото еквивалентно представяне на тип данни (табличното представяне е взето от тук):
| Оракул | MySQL | |||
|---|---|---|---|---|
| 1 | BFILE | Указател към двоичен файл, ⇐ 4G | VARCHAR(255) | |
| 2 | BINARY_FLOAT | 32-битово число с плаваща запетая | ПЛАВАНЕ | |
| 3 | BINARY_DOUBLE | 64-битово число с плаваща запетая | ДВОЙНО | |
| 4 | BLOB | Бинарен голям обект, ⇐ 4G | LONGBLOB | |
| 5 | CHAR(n), CHARACTER(n) | Низ с фиксирана дължина, 1 ⇐ n ⇐ 255 | CHAR(n), CHARACTER(n) | |
| 6 | CHAR(n), CHARACTER(n) | Низ с фиксирана дължина, 256 ⇐ n ⇐ 2000 | VARCHAR(n) | |
| 7 | CLOB | Символен голям обект, ⇐ 4G | ДЪЛЪГ ТЕКСТ | |
| 8 | ДАТА | Дата и час | DATETIME | |
| 9 | DECIMAL(p,s), DEC(p,s) | Номер с фиксирана точка | DECIMAL(p,s), DEC(p,s) | |
| 10 | ДВОЙНА ТОЧНОСТ | Число с плаваща запетая | ДВОЙНА ТОЧНОСТ | |
| 11 | FLOAT(p) | Число с плаваща запетая | ДВОЙНО | |
| 12 | ЦЯЛО ЧИСЛО, INT | 38-цифрено цяло число | INT | DECIMAL(38) |
| 13 | ИНТЕРВАЛ ГОДИНА(p) ДО МЕСЕЦ | Интервал от дата | VARCHAR(30) | |
| 14 | ИНТЕРВАЛ ДЕН(p) ДО СЕКУНД(и) | Ден и времеви интервал | VARCHAR(30) | |
| 15 | ДЪЛГО | Данни за знаци, ⇐ 2G | ДЪЛЪГ ТЕКСТ | |
| 16 | LONG RAW | Двоични данни, ⇐ 2G | LONGBLOB | |
| 17 | NCHAR(n) | Низ UTF-8 с фиксирана дължина, 1 ⇐ n ⇐ 255 | NCHAR(n) | |
| 18 | NCHAR(n) | Низ UTF-8 с фиксирана дължина, 256 ⇐ n ⇐ 2000 | NVARCHAR(n) | |
| 19 | NCHAR VARYING(n) | Утф-8 низ с различна дължина, 1 ⇐ n ⇐ 4000 | NCHAR VARYING(n) | |
| 20 | NCLOB | Unicode низ с променлива дължина, ⇐ 4G | NVARCHAR(макс.) | |
| 21 | NUMBER(p,0), NUMBER(p) | 8-битово цяло число, 1 <=p <3 | TINYINT | (0 до 255) |
| 16-битово цяло число, 3 <=p <5 | SMALLINT | |||
| 32-битово цяло число, 5 <=p <9 | INT | |||
| 64-битово цяло число, 9 <=p <19 | ГОЛЯМ | |||
| Число с фиксирана точка, 19 <=p <=38 | DECIMAL(p) | |||
| 22 | NUMBER(p,s) | Число с фиксирана точка, s> 0 | DECIMAL(p,s) | |
| 23 | NUMBER, NUMBER(*) | Число с плаваща запетая | ДВОЙНО | |
| 24 | NUMERIC(p,s) | Номер с фиксирана точка | ЧИСЛО(p,s) | |
| 25 | NVARCHAR2(n) | UTF-8 низ с променлива дължина, 1 ⇐ n ⇐ 4000 | NVARCHAR(n) | |
| 26 | RAW(n) | Двоичен низ с променлива дължина, 1 ⇐ n ⇐ 255 | БИНАРЕН(n) | |
| 27 | RAW(n) | Двоичен низ с променлива дължина, 256 ⇐ n ⇐ 2000 | VARBINARY(n) | |
| 28 | ИСТИНСКИ | Число с плаваща запетая | ДВОЙНО | |
| 29 | ROWID | Физически адрес на ред | CHAR(10) | |
| 30 | SMALLINT | 38-цифрено цяло число | DECIMAL(38) | |
| 31 | TIMESTAMP(p) | Дата и час с дроб | DATETIME(p) | |
| 32 | TIMESTAMP(p) С ЧАСОВА ЗОНА | Дата и час с дроб и часова зона | DATETIME(p)  | |
| 33 | UROWID(n) | Логически адреси на редове, 1 ⇐ n ⇐ 4000 | VARCHAR(n) | |
| 34 | VARCHAR(n) | Низ с променлива дължина, 1 ⇐ n ⇐ 4000 | VARCHAR(n) | |
| 35 | VARCHAR2(n) | Низ с променлива дължина, 1 ⇐ n ⇐ 4000 | VARCHAR(n) | |
| 36 | XMLTYPE | XML данни | ДЪЛЪГ ТЕКСТ | |
Атрибути и опции за тип данни:
| Oracle | MySQL |
| Семантика на размера на колоните BYTE и CHAR | Размерът винаги е в знаци |
Транзакции
Percona Server използва XtraDB (разширена версия на InnoDB) като основна машина за съхранение за обработка на транзакционни данни; въпреки че различни механизми за съхранение могат да бъдат алтернативен избор за обработка на транзакции като TokuDB (оттеглени) и механизми за съхранение на MyRocks.
Въпреки че има предимства и ползи от използването или проучването на MyRocks с XtraDB, последният е по-стабилен и де факто двигател за съхранение, който Percona Server използва и е активиран по подразбиране, така че ще използваме този механизъм за съхранение като основа за миграция по отношение на към транзакции.
По подразбиране Percona Server/MySQL има променлива за автоматично записване, зададена на ON, което означава, че трябва изрично да обработвате транзакционни оператори, за да се възползвате от ROLLBACK за игнориране на промените или възползване от използването на SAVEPOINT.
По същество това е същата концепция, която Oracle използва по отношение на commit, rollback и savepoints.
За изрични транзакции това означава, че трябва да използвате START TRANSACTION/BEGIN;
В противен случай, ако трябва да деактивирате автоматичното записване, трябва изрично да COMMIT през цялото време за вашите изявления, което изисква промени във вашите данни.
Двойна маса
MySQL има двойна съвместимост с Oracle, която е предназначена за съвместимост на бази данни с помощта на фиктивна таблица, а именно DUAL.
Това отговаря на използването на DUAL от Oracle, така че всички съществуващи изрази във вашето приложение, които използват DUAL, може да не изискват промени при миграция към Percona Server.
Клаузата FROM на Oracle е задължителна за всеки оператор SELECT, така че базата данни на Oracle използва DUAL таблица за оператор SELECT, където не се изисква име на таблица.
В MySQL клаузата FROM не е задължителна, така че таблицата DUAL не е необходима. Въпреки това таблицата DUAL не работи точно по същия начин, както за Oracle, но за прости SELECT в Percona Server това е добре.
Вижте следния пример по-долу:
В 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Но в 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)Забележка:DESC DUAL синтаксисът не работи в MySQL и резултатите също се различават, тъй като CURRENT_TIMESTAMP (използва тип данни TIMESTAMP) в MySQL не включва часовата зона.
SYSDATE
Функцията SYSDATE на Oracle е почти същата в MySQL.
MySQL връща дата и час и е функция, която изисква () (затваряне и отваряне на скоби без необходими аргументи. За да демонстрирате това по-долу, ето Oracle и MySQL относно използването на SYSDATE.
В Oracle използването на обикновен SYSDATE просто връща датата на деня без часа. Но за да получите часа и датата, използвайте TO_CHAR, за да преобразувате датата и часа в желания формат; докато в MySQL може да нямате нужда от него, за да получите датата и часа, тъй като връща и двете.
Вижте примера по-долу.
В 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Но в MySQL:
mysql> SELECT SYSDATE() FROM DUAL;
+---------------------+
| SYSDATE() |
+---------------------+
| 2019-02-15 20:37:36 |
+---------------------+
1 row in set (0.00 sec)Ако искате да форматирате датата, MySQL има функция DATE_FORMAT().
Можете да проверите документацията за дата и час на MySQL за повече информация.
ДО_ДАТА
Еквивалентът на TO_DATE на Oracle в MySQL е функцията STR_TO_DATE().
Той е почти идентичен с този в Oracle:връща типа данни DATE, докато в MySQL връща типа данни DATETIME.
Оракул:
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)СИНОНИМ
В MySQL няма такава поддръжка, нито еквивалентност за SYNONYM в Oracle.
Възможна алтернатива с MySQL е използването на VIEW.
Въпреки че SYNONYM може да се използва за създаване на псевдоним на отдалечена таблица,
напр.
CREATE PUBLIC SYNONYM emp_table FOR [email protected]В MySQL можете да се възползвате от използването на FEDERATED storage engine.
напр.
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';Или можете да опростите процеса със синтаксис CREATE SERVER, така че когато създавате таблица, действаща като ваш СИНОНИМ за достъп до отдалечена таблица, ще бъде по-лесно. Вижте документацията за повече информация по въпроса.
Поведение на празен низ и NULL
Обърнете внимание, че в Percona Server / MySQL празният низ не е NULL, докато Oracle третира празния низ като нулеви стойности.
В Oracle:
SQL> SELECT CASE WHEN '' IS NULL THEN 'Yes' ELSE 'No' END AS "Null Eval" FROM dual;
Nul
---
YesВ 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)Последователности
В MySQL няма абсолютно същия подход към това, което Oracle прави за SEQUENCE.
Въпреки че има някои публикации, които симулират функционалността на този подход, може да сте в състояние да опитате да получите следващия ключ, като използвате LAST_INSERT_ID(), стига клъстерираният индекс на вашата таблица, PRIMARY KEY, е дефиниран с <<липсва ли нещо?>>
Функции за символен низ
За разлика от Oracle, MySQL / Percona Server има шепа низови функции, но не толкова много полезни функции, вградени в базата данни.
Би било твърде дълго да го обсъждаме тук един по един, но можете да проверите документацията от MySQL и да сравните това с низовите функции на Oracle.
DML изявления
Инструкциите Insert/Update/Delete от Oracle са съвместими в MySQL.
ВМЕСЕТЕ ВСИЧКО/ПЪРВО ВМЕСЕТЕ на Oracle не се поддържа в MySQL.
В противен случай ще трябва да посочите своите MySQL заявки една по една.
напр.
В 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 реда.
Но в MySQL трябва да стартирате вмъкването едно по едно:
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 не се сравнява с начина, по който се използва в Oracle, където можете да се възползвате от условията, като добавите ключова дума WHEN във вашия синтаксис; в този случай няма еквивалентна опция в MySQL / Percona Server.
Следователно вашето алтернативно решение за това е да използвате процедури.
Символ „+“ за външни връзки
В Oracle използването на оператор + за ляво и дясно свързване в момента не се поддържа в MySQL, тъй като операторът + се използва само за аритметични решения.
Следователно, ако имате оператор + в съществуващите си Oracle SQL изрази, трябва да замените това с LEFT JOIN или RIGHT JOIN.
Може да искате да проверите официалната документация за „Опростяване на външното присъединяване“ на MySQL.
ЗАПОЧНЕТЕ С..СВЪРЗВАНЕ ОТ
Oracle използва START WITH..CONNECT BY за йерархични заявки.
Започвайки с MySQL / Percona 8.0, има поддръжка за генериране на йерархични резултати от данни, които използват модели като списък на съседство или модели на вложен набор. Това се нарича Common Table Expressions (CTE) в MySQL.
Подобно на PostgreSQL, MySQL използва WITH RECURSIVE синтаксис за йерархични заявки, така че преведете CONNECT BY изявление в WITH RECURSIVE изявление.
Вижте по-долу как се различава от ORACLE и в MySQL / Percona Server.
В 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; И в 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 в MySQL / Percona?
MySQL / Percona RDBMS има различен подход от PL/SQL на Oracle.
MySQL използва съхранени процедури или съхранени функции, което е подобно на PL/SQL и синтаксис използва BEGIN..END синтаксис.
PL/SQL на Oracle се компилира преди изпълнение, когато се зареди на сървъра, докато MySQL се компилира и съхранява в кеша, когато е извикан.
Може да искате да проверите тази документация като справочник за преобразуване на вашия PL/SQL в MySQL.
Инструменти за мигриране
Направих проучване за всякакви инструменти, които биха могли да бъдат де факто стандарт за миграция, но не можах да намеря добър отговор.
Въпреки това намерих sqlines и изглежда просто, но обещаващо.
Въпреки че не се гмурнах дълбоко в него, уебсайтът предлага шепа прозрения, които биха могли да ви помогнат при мигрирането от Oracle към MySQL/Percona Server. Има и платени инструменти като това и това.
Търсих и в github, но не намерих нищо по-привлекателно като решение на проблема. Следователно, ако се стремите да мигрирате от Oracle и към Amazon, те имат AWS Schema Conversion Tool, за който се поддържа мигриране от Oracle към MySQL.
Като цяло причината, поради която миграцията не е лесна за изпълнение, е главно защото Oracle RDBMS е такъв звяр с много функции, които Percona Server / MySQL или MariaDB RDBMS все още нямат.
Както и да е, ако намерите или знаете инструменти, които намирате за полезни и полезни за мигриране от Oracle към MySQL / Percona Server, моля, оставете коментар в този блог!
Тестване
Като част от вашия план за миграция, тестването е жизненоважна задача, която играе много важна роля и влияе върху решението ви по отношение на миграцията.
Инструментът dbdeployer (порт на MySQL Sandbox) е много полезен инструмент, от който можете да се възползвате. Това е доста лесно за вас да опитате и тествате различни подходи и ви спестява време, вместо да настройвате целия стек, ако целта ви е първо да опитате и тествате платформата RDBMS.
За тестване на вашите съхранени в SQL подпрограми (функции или процедури), тригери, събития, ви предлагам да използвате тези инструменти mytap или рамката за тестване на модули на Google.
Percona също така предлага редица инструменти, които са достъпни за изтегляне на техния уебсайт. Разгледайте Percona Toolkit тук. Можете да изберете инструментите според вашите нужди, особено за задачи за тестване и производствена употреба.
Като цяло нещата, които трябва да имате предвид като насоки, когато правите тест за вашия MySQL сървър, са:
- След инсталирането трябва да помислите за някои настройки. Разгледайте този блог на Percona за помощ.
- Направете някои сравнителни тестове и тестване на натоварване за вашата конфигурация на текущия си възел. Проверете mysqlslap и sysbench, които могат да ви помогнат с това. Вижте също нашия блог „Как да сравните производителността на MySQL и MariaDB с помощта на SysBench“.
- Проверете вашите DDL дали са правилно дефинирани като типове данни, ограничения, клъстерирани и вторични индекси или дялове, ако имате такива.
- Проверете своя DML, особено дали синтаксисът е правилен и запазвате данните правилно, както се очаква.
- Проверете съхранените си рутинни действия, събития, тригери, за да се уверите, че изпълняват/връщат очакваните резултати.
- Проверете дали изпълняваните ви заявки са ефективни. Предлагам ви да се възползвате от инструментите с отворен код или да опитате нашия продукт ClusterControl. Той предлага наблюдение/наблюдаемост, особено на вашия MySQL / Percona сървър. Можете да използвате ClusterControl тук, за да наблюдавате вашите заявки и неговия план за заявки, за да сте сигурни, че са ефективни.
