sql >> Base de Datos >  >> RDS >> Mysql

Cómo migrar de Oracle a MySQL / Percona Server

Migrar de Oracle a MySQL/Percona Server no es una tarea trivial. Aunque cada vez es más fácil, sobre todo con la llegada de MySQL 8.0 y Percona anunció Percona Server para MySQL 8.0 GA. Además de planificar su migración de Oracle a Percona Server, debe asegurarse de comprender el propósito y la funcionalidad de por qué tiene que ser Percona Server.

Este blog se centrará en la migración de Oracle a Percona Server como su base de datos de destino específica de elección. Hay una página en el sitio web de Oracle sobre información complementaria para desarrolladores de SQL para migraciones de MySQL que se puede usar como referencia para la migración planificada. Este blog no cubrirá el proceso general de migración, ya que es un proceso largo. Pero es de esperar que proporcione suficiente información básica para servir como guía para su proceso de migración.

Dado que Percona Server es una bifurcación de MySQL, casi todas las características que vienen con MySQL están presentes en Percona Server. Entonces, cualquier referencia de MySQL aquí también es aplicable a Percona Server. Anteriormente escribimos en un blog sobre la migración de Oracle Database a PostgreSQL. Reiteraré nuevamente las razones por las que uno consideraría migrar de Oracle a un RDBMS de código abierto como PostgreSQL o Percona Server/MySQL/MariaDB.

  1. Costo:como sabrá, el costo de la licencia de Oracle es muy alto y hay un costo adicional para algunas funciones, como el particionamiento y la alta disponibilidad. Entonces, en general, es muy caro.
  2. Licencias flexibles de código abierto y fácil disponibilidad de proveedores de nube pública como AWS.
  3. Benefíciese de los complementos de código abierto para mejorar el rendimiento.

Estrategia de Planificación y Desarrollo

La migración de Oracle a Percona Server 8.0 puede ser una molestia, ya que hay muchos factores clave que deben tenerse en cuenta y abordarse. Por ejemplo, Oracle puede ejecutarse en una máquina con Windows Server, pero Percona Server no es compatible con Windows. Aunque puede compilarlo para Windows, Percona en sí no ofrece ningún soporte para Windows. También debe identificar los requisitos de arquitectura de su base de datos, ya que Percona Server no está diseñado para OLAP (procesamiento analítico en línea) o aplicaciones de almacenamiento de datos. Percona Server/MySQL RDBMS son perfectos para OLTP (procesamiento de transacciones en línea).

Identificando el aspecto clave de la arquitectura de su base de datos, por ejemplo, si su arquitectura Oracle actual implementa MAA (Arquitectura Máxima Disponible) con Data Guard ++ Oracle RAC (Cluster de Aplicación Real), debe determinar su equivalencia en Percona Server. No hay una respuesta directa para esto dentro de MySQL/Percona Server. Sin embargo, puede elegir entre una replicación síncrona, una replicación asíncrona (Percona XtraDB Cluster aún se encuentra actualmente en la versión 5.7.x) o con Group Replication. Luego, existen múltiples alternativas que puede implementar para su propia solución de alta disponibilidad. Por ejemplo, (por nombrar algunos) usando la pila Corosync/Pacemaker/DRBD/Linux, o usando MHA (MySQL High Availability), o usando la pila Keepalived/HaProxy/ProxySQL, o simplemente confíe en ClusterControl que admite Keepalived, HaProxy, ProxySQL, Garbd y Maxscale para sus soluciones de alta disponibilidad.

Por otro lado, la pregunta que también debe considerar como parte del plan es "¿Cómo proporcionará soporte Percona y quién nos ayudará cuando Percona Server encuentre un error o qué tan urgente es cuando necesitemos ayuda?". Una cosa a considerar también es el presupuesto, si el propósito de la migración de la base de datos empresarial a un RDBMS de código abierto es para reducir costos.

Existen diferentes opciones, desde la planificación de la migración hasta las cosas que debe hacer como parte de su estrategia de desarrollo. Dichas opciones incluyen interactuar con expertos en el campo de MySQL/Percona Server y eso nos incluye a nosotros aquí en Variousnines. Hay muchas firmas de consultoría de MySQL que pueden ayudarlo con esto, ya que la migración de Oracle a MySQL requiere mucha experiencia y conocimientos en el área del servidor MySQL. Esto no debe limitarse a la base de datos, sino que debe cubrir la experiencia en escalabilidad, redundancia, copias de seguridad, alta disponibilidad, seguridad, monitoreo/observabilidad, recuperación y participación en sistemas de misión crítica. En general, debe comprender su perspectiva arquitectónica sin exponer la confidencialidad de sus datos.

Valoración o Verificación Preliminar

La copia de seguridad de sus datos, incluidas las configuraciones o los archivos de instalación, los ajustes del kernel y los scripts de automatización, no se dejarán en el olvido. Es una tarea obvia, pero antes de migrar, siempre asegure todo primero, especialmente cuando cambie a una plataforma diferente.

También debe evaluar que sus aplicaciones sigan las convenciones de ingeniería de software actualizadas y asegurarse de que sean independientes de la plataforma. Estas prácticas pueden ser beneficiosas para usted, especialmente cuando se cambia a una plataforma de base de datos diferente, como Percona Server para MySQL.

Tenga en cuenta que el sistema operativo que requiere Percona Server puede ser un obstáculo si su aplicación y base de datos se ejecutan en un servidor Windows y la aplicación depende de Windows; entonces esto podría ser mucho trabajo! Recuerde siempre que Percona Server se encuentra en una plataforma diferente:es posible que la perfección no esté garantizada, pero se puede lograr lo suficientemente cerca.

Por último, asegúrese de que el hardware de destino esté diseñado para funcionar de manera factible con los requisitos del servidor de Percona o que esté libre de errores al menos (consulte aquí). Puede considerar realizar pruebas de estrés primero con Percona Server antes de retirarse de manera confiable de su base de datos Oracle.

Lo que debe saber

Vale la pena señalar que en Percona Server / MySQL, puede crear múltiples bases de datos, mientras que Oracle no viene con la misma funcionalidad que MySQL.

En MySQL, físicamente, un esquema es sinónimo de una base de datos. Puede sustituir la palabra clave SCHEMA en lugar de DATABASE en la sintaxis SQL de MySQL, por ejemplo, usando CREATE SCHEMA en lugar de CREAR BASE DE DATOS; mientras que Oracle tiene una distinción de esto. Un esquema representa solo una parte de una base de datos:las tablas y otros objetos que pertenecen a un solo usuario. Normalmente, existe una relación de uno a uno entre la instancia y la base de datos.

Por ejemplo, en una configuración de replicación equivalente en Oracle (por ejemplo, Real Application Clusters o RAC), tiene varias instancias que acceden a una única base de datos. Esto le permite iniciar Oracle en varios servidores, pero todos accediendo a los mismos datos. Sin embargo, en MySQL, puede permitir el acceso a múltiples bases de datos desde sus múltiples instancias e incluso puede filtrar qué bases de datos/esquema puede replicar en un nodo de MySQL.

Haciendo referencia a uno de nuestros blogs anteriores, se aplica el mismo principio cuando se habla de convertir su base de datos con las herramientas disponibles que se encuentran en Internet.

No existe tal herramienta que pueda convertir al 100% la base de datos Oracle en Percona Server / MySQL; parte será trabajo manual.

Consulte las siguientes secciones para conocer las cosas que debe tener en cuenta cuando se trata de la migración y la verificación del resultado lógico de SQL.

Asignación de tipos de datos

MySQL / Percona Server tiene una cantidad de tipos de datos que es casi igual a Oracle pero no tan rico en comparación con Oracle. Pero desde la llegada de la versión 5.7.8 de MySQL, se admite un tipo de datos JSON nativo.

A continuación se muestra su representación equivalente de tipo de datos (la representación tabular se toma de aquí):

MySQL
Oráculo
1 BARCHIVO Puntero a archivo binario, ⇐ 4G VARCHAR(255)
2 BINARY_FLOAT Número de coma flotante de 32 bits FLOTACIÓN
3 BINARIO_DOBLE Número de coma flotante de 64 bits DOBLE
4 BLOQUEO Objeto binario grande, ⇐ 4G BLOB LARGO
5 CARÁCTER(n), CARÁCTER(n) Cadena de longitud fija, 1 ⇐ n ⇐ 255 CARÁCTER(n), CARÁCTER(n)
6 CARÁCTER(n), CARÁCTER(n) Cadena de longitud fija, 256 ⇐ n ⇐ 2000 VARCHAR(n)
7 CLOB Objeto grande de carácter, ⇐ 4G TEXTO LARGO
8 FECHA Fecha y hora FECHAHORA
9 DECIMAL(p,s), DEC(p,s) Número de punto fijo DECIMAL(p,s), DEC(p,s)
10 DOBLE PRECISIÓN Número de coma flotante DOBLE PRECISIÓN
11 FLOTACIÓN(p) Número de coma flotante DOBLE
12 ENTERO, INT entero de 38 dígitos INT DECIMALES(38)
13 INTERVALO AÑO(p) A MES Intervalo de fechas VARCHAR(30)
14 INTERVALO DE DÍA(p) A SEGUNDO(s) Día e intervalo de tiempo VARCHAR(30)
15 LARGO Datos de personajes, ⇐ 2G TEXTO LARGO
16 LARGO CRUDO Datos binarios, ⇐ 2G BLOB LARGO
17 NCHAR(n) Cadena UTF-8 de longitud fija, 1 ⇐ n ⇐ 255 NCHAR(n)
18 NCHAR(n) Cadena UTF-8 de longitud fija, 256 ⇐ n ⇐ 2000 NVARCHAR(n)
19 NCHAR VARIABLE(n) Cadena UTF-8 de longitud variable, 1 ⇐ n ⇐ 4000 NCHAR VARIABLE(n)
20 NCLOB Cadena Unicode de longitud variable, ⇐ 4G NVARCHAR(máximo)
21 NÚMERO(p,0), NÚMERO(p) Entero de 8 bits, 1 <=p <3 TINYINT (0 a 255)
entero de 16 bits, 3 <=p <5 PEQUEÑO
Entero de 32 bits, 5 <=p <9 INT
entero de 64 bits, 9 <=p <19 BIGINTO
Número de punto fijo, 19 <=p <=38 DECIMAL(p)
22 NÚMERO(p,s) Número de punto fijo, s> 0 DECIMAL(p,s)
23 NÚMERO, NÚMERO(*) Número de coma flotante DOBLE
24 NUMÉRICO(p,s) Número de punto fijo NUMÉRICO(p,s)
25 NVARCHAR2(n) Cadena UTF-8 de longitud variable, 1 ⇐ n ⇐ 4000 NVARCHAR(n)
26 RAW(n) Cadena binaria de longitud variable, 1 ⇐ n ⇐ 255 BINARIO(n)
27 RAW(n) Cadena binaria de longitud variable, 256 ⇐ n ⇐ 2000 VARBINARIO(n)
28 REAL Número de coma flotante DOBLE
29 ROWID Dirección de fila física CARÁCTER(10)
30 PEQUEÑO entero de 38 dígitos DECIMALES(38)
31 TIMESTAMP(p) Fecha y hora con fracción FECHAHORA(p)
32 TIMESTAMP(p) CON ZONA HORARIA Fecha y hora con fracción y zona horaria FECHAHORA(p)
33 UROWID(n) Direcciones de fila lógica, 1 ⇐ n ⇐ 4000 VARCHAR(n)
34 VARCHAR(n) Cadena de longitud variable, 1 ⇐ n ⇐ 4000 VARCHAR(n)
35 VARCHAR2(n) Cadena de longitud variable, 1 ⇐ n ⇐ 4000 VARCHAR(n)
36 TIPOXML Datos XML TEXTO LARGO

Atributos y opciones de tipo de datos:

Oraculo MySQL
Semántica de tamaño de columna BYTE y CHAR El tamaño siempre está en caracteres

Transacciones

Percona Server usa XtraDB (una versión mejorada de InnoDB) como su principal motor de almacenamiento para manejar datos transaccionales; aunque varios motores de almacenamiento pueden ser una opción alternativa para manejar transacciones como TokuDB (obsoleto) y los motores de almacenamiento MyRocks.

Si bien el uso o la exploración de MyRocks con XtraDB tiene ventajas y beneficios, este último es un motor de almacenamiento más robusto y de facto que el que usa Percona Server y está habilitado de forma predeterminada, por lo que usaremos este motor de almacenamiento como base para la migración con respecto a a las transacciones.

De forma predeterminada, Percona Server / MySQL tiene la variable de confirmación automática establecida en ON, lo que significa que debe manejar declaraciones transaccionales explícitamente para aprovechar ROLLBACK para ignorar cambios o aprovechar el uso de SAVEPOINT.

Es básicamente el mismo concepto que usa Oracle en términos de confirmación, retrocesos y puntos de guardado.

Para transacciones explícitas, esto significa que debe usar START TRANSACTION/BEGIN; ; COMPROMETER; sintaxis.

De lo contrario, si tiene que deshabilitar la confirmación automática, debe COMMITIR explícitamente todo el tiempo para sus declaraciones que requieren cambios en sus datos.

Mesa doble

MySQL tiene la compatibilidad dual con Oracle, que está destinada a la compatibilidad de las bases de datos que utilizan una tabla ficticia, a saber, DUAL.

Esto se adapta al uso de DUAL de Oracle, por lo que cualquier declaración existente en su aplicación que use DUAL podría no requerir cambios al migrar a Percona Server.

La cláusula Oracle FROM es obligatoria para cada declaración SELECT, por lo que la base de datos Oracle usa la tabla DUAL para la declaración SELECT donde no se requiere un nombre de tabla.

En MySQL, la cláusula FROM no es obligatoria, por lo que la tabla DUAL no es necesaria. Sin embargo, la tabla DUAL no funciona exactamente igual que para Oracle, pero para SELECT simples en Percona Server, está bien.

Vea el siguiente ejemplo a continuación:

En Oráculo,

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

Pero en 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)

Nota:el DESC DUAL la sintaxis no funciona en MySQL y los resultados también difieren ya que CURRENT_TIMESTAMP (usa el tipo de datos TIMESTAMP) en MySQL no incluye la zona horaria.

SISTEMA

La función SYSDATE de Oracle es casi la misma en MySQL.

MySQL devuelve la fecha y la hora y es una función que requiere () (cerrar y abrir paréntesis sin necesidad de argumentos. Para demostrar esto a continuación, aquí está Oracle y MySQL sobre el uso de SYSDATE.

En Oracle, el uso de SYSDATE simple solo devuelve la fecha del día sin la hora. Pero para obtener la hora y la fecha, use TO_CHAR para convertir la hora de la fecha al formato deseado; mientras que en MySQL, es posible que no lo necesite para obtener la fecha y la hora, ya que devuelve ambas.

Vea el ejemplo a continuación.

En Oráculo:

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

Pero en MySQL:

mysql> SELECT SYSDATE() FROM DUAL;
+---------------------+
| SYSDATE()           |
+---------------------+
| 2019-02-15 20:37:36 |
+---------------------+
1 row in set (0.00 sec)

Si desea formatear la fecha, MySQL tiene una función DATE_FORMAT().

Puede consultar la documentación de fecha y hora de MySQL para obtener más información.

HASTA_FECHA

El equivalente TO_DATE de Oracle en MySQL es la función STR_TO_DATE().

Es casi idéntico al de Oracle:devuelve el tipo de datos DATE, mientras que en MySQL devuelve el tipo de datos DATETIME.

Oráculo:

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)

SINÓNIMO

En MySQL, no existe tal soporte ni ninguna equivalencia para SYNONYM en Oracle.

Una posible alternativa puede ser posible con MySQL usando VIEW.

Aunque SYNONYM se puede usar para crear un alias de una tabla remota,

por ejemplo

CREATE PUBLIC SYNONYM emp_table FOR [email protected]

En MySQL, puede aprovechar el uso del motor de almacenamiento FEDERADO.

por ejemplo

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';

O puede simplificar el proceso con la sintaxis CREATE SERVER, de modo que al crear una tabla que actúe como su SINÓNIMO para acceder a una tabla remota, será más fácil. Consulte la documentación para obtener más información al respecto.

Comportamiento de cadena vacía y NULL

Tenga en cuenta que en Percona Server / MySQL, la cadena vacía no es NULL, mientras que Oracle trata la cadena vacía como valores nulos.

En Oráculo:

SQL> SELECT CASE WHEN '' IS NULL THEN 'Yes' ELSE 'No' END AS "Null Eval" FROM dual;
Nul
---
Yes

En 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)

Secuencias

En MySQL, no existe exactamente el mismo enfoque de lo que hace Oracle para SEQUENCE.

Aunque hay algunas publicaciones que simulan la funcionalidad de este enfoque, es posible que pueda intentar obtener la siguiente clave usando LAST_INSERT_ID() siempre que el índice agrupado de su tabla, PRIMARY KEY, esté definido con <<¿falta algo?>>

Funciones de cadenas de caracteres

A diferencia de Oracle, MySQL/Percona Server tiene un puñado de funciones de cadena pero no tantas funciones útiles integradas en la base de datos.

Sería demasiado largo discutirlo aquí uno por uno, pero puede consultar la documentación de MySQL y comparar esto con las funciones de cadena de Oracle.

Declaraciones DML

Las declaraciones Insert/Update/Delete de Oracle son congruentes en MySQL.

INSERTAR TODO/INSERTAR PRIMERO de Oracle no es compatible con MySQL.

De lo contrario, deberá indicar sus consultas de MySQL una por una.

por ejemplo

En Oráculo:

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 filas creadas.

Pero en MySQL, debe ejecutar la inserción de una en una:

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)

INSERTAR TODO/INSERTAR PRIMERO no se compara con cómo se usa en Oracle, donde puede aprovechar las condiciones agregando una palabra clave CUANDO en su sintaxis; no hay una opción equivalente en MySQL / Percona Server en este caso.

Por lo tanto, su solución alternativa en esto es usar procedimientos.

Símbolo de uniones externas "+"

En Oracle, actualmente no se admite el uso del operador + para combinaciones izquierda y derecha en MySQL, ya que el operador + solo se usa para decisiones aritméticas.

Por lo tanto, si tiene un operador + en sus declaraciones Oracle SQL existentes, debe reemplazarlo con LEFT JOIN o RIGHT JOIN.

Es posible que desee consultar la documentación oficial de "Simplificación de combinación externa" de MySQL.

COMENZAR CON...CONECTAR POR

Oracle usa START WITH..CONNECT BY para consultas jerárquicas.

A partir de MySQL/Percona 8.0, hay soporte para generar resultados de datos jerárquicos que utilizan modelos como listas de adyacencia o modelos de conjuntos anidados. Esto se llama Expresiones de tabla comunes (CTE) en MySQL.

Similar a PostgreSQL, MySQL usa CON RECURSIVO sintaxis para consultas jerárquicas, así que traduce CONECTAR POR declaración en CON RECURSIVO declaración.

Consulte a continuación en qué se diferencia de ORACLE y en MySQL / Percona Server.

En Oráculo:

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;

Y en 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 en MySQL/Percona?

MySQL/Percona RDBMS tiene un enfoque diferente al PL/SQL de Oracle.

MySQL usa procedimientos almacenados o funciones almacenadas, que es similar a PL/SQL y la sintaxis usa BEGIN..END sintaxis.

PL/SQL de Oracle se compila antes de la ejecución cuando se carga en el servidor, mientras que MySQL se compila y almacena en la memoria caché cuando se invoca.

Es posible que desee consultar esta documentación como guía de referencia para convertir su PL/SQL a MySQL.

Herramientas de migración

Investigué algunas herramientas que podrían ser un estándar de facto para la migración, pero no pude encontrar una buena respuesta.

Sin embargo, encontré sqlines y parece simple pero prometedor.

Si bien no me sumergí profundamente en él, el sitio web ofrece un puñado de ideas que podrían ayudarlo a migrar de Oracle a MySQL/Percona Server. También hay herramientas pagas como esta y esta.

También busqué en github pero no encontré nada más atractivo como solución al problema. Por lo tanto, si tiene como objetivo migrar de Oracle a Amazon, tienen la herramienta de conversión de esquemas de AWS para la que se admite la migración de Oracle a MySQL.

En general, la razón por la cual la migración no es algo fácil de hacer es principalmente porque Oracle RDBMS es una bestia con muchas funciones que Percona Server/MySQL o MariaDB RDBMS aún no tienen.

De todos modos, si encuentra o conoce alguna herramienta que le resulte útil y beneficiosa para migrar de Oracle a MySQL/Percona Server, ¡deje un comentario en este blog!

Pruebas

Como parte de su plan de migración, la prueba es una tarea vital que juega un papel muy importante y afecta su decisión con respecto a la migración.

La herramienta dbdeployer (un puerto de MySQL Sandbox) es una herramienta muy útil que puede aprovechar. Es bastante fácil para usted probar y probar diferentes enfoques y le ahorra tiempo, en lugar de configurar toda la pila si su propósito es probar primero la plataforma RDBMS.

Para probar sus rutinas almacenadas en SQL (funciones o procedimientos), disparadores, eventos, le sugiero que use estas herramientas mytap o el marco de pruebas unitarias de Google.

Percona también ofrece una serie de herramientas que están disponibles para descargar en su sitio web. Consulte el kit de herramientas de Percona aquí. Puede elegir las herramientas según sus necesidades, especialmente para tareas de prueba y uso de producción.

En general, las cosas que debe tener en cuenta como pautas al realizar una prueba para su servidor MySQL son:

  • Después de la instalación, debe considerar realizar algunos ajustes. Consulte este blog de Percona para obtener ayuda.
  • Haga algunos puntos de referencia y pruebas de carga de estrés para su configuración en su nodo actual. Consulte mysqlslap y sysbench que pueden ayudarlo con esto. Consulte también nuestro blog "Cómo comparar el rendimiento de MySQL y MariaDB usando SysBench".
  • Verifique si sus DDL están definidos correctamente, como tipos de datos, restricciones, índices agrupados y secundarios, o particiones, si las tiene.
  • Verifique su DML, especialmente si la sintaxis es correcta y está guardando los datos correctamente como se esperaba.
  • Revise sus rutinas, eventos y disparadores almacenados para asegurarse de que se ejecuten o devuelvan los resultados esperados.
  • Verifique que sus consultas en ejecución sean eficaces. Le sugiero que aproveche las herramientas de código abierto o pruebe nuestro producto ClusterControl. Ofrece monitoreo/observabilidad especialmente de su servidor MySQL/Percona. Puede usar ClusterControl aquí para monitorear sus consultas y su plan de consultas para asegurarse de que funcionen.