Si bien comparte la misma herencia con MySQL, MariaDB es una base de datos diferente. A lo largo de los años, a medida que se lanzaban nuevas versiones de MySQL y MariaDB, ambos proyectos se diferenciaron en dos plataformas RDBMS diferentes.
MariaDB se convierte en la principal distribución de bases de datos en muchas plataformas Linux y está ganando gran popularidad en estos días. Al mismo tiempo, se convierte en un sistema de base de datos muy atractivo para muchas corporaciones. Obtiene características que se acercan a las necesidades de la empresa, como cifrado, copias de seguridad activas o compatibilidad con bases de datos propietarias.
Pero, ¿cómo afectan las nuevas funciones a la compatibilidad de MariaDB con MySQL? ¿Sigue siendo un reemplazo para MySQL? ¿Cómo amplifican los últimos cambios el proceso de migración? Intentaremos responder eso en este artículo.
Lo que necesita saber antes de actualizar
MariaDB y MySQL difieren significativamente entre sí en los últimos dos años, especialmente con la llegada de sus versiones más recientes:MySQL 8.0, MariaDB 10.3 y MariaDB 10.4 RC (discutimos las nuevas características de MariaDB 10.4 RC recientemente, así que si desea lea más sobre lo que viene en 10.4, consulte dos blogs de mi colega Krzysztof, What's New in MariaDB 10.4 y el segundo sobre What's New in MariaDB Cluster 10.4).
Con el lanzamiento de MariaDB 10.3, MariaDB sorprendió a muchos, ya que ya no es un reemplazo directo de MySQL. MariaDB ya no fusiona nuevas características de MySQL con MariaDB noir para resolver errores de MySQL. No obstante, la versión 10.3 ahora se está convirtiendo en una alternativa real a Oracle MySQL Enterprise, así como a otras bases de datos de propiedad empresarial como Oracle 12c (MSSQL en la versión 10.4).
Comprobación preliminar y limitaciones
La migración es un proceso complejo sin importar a qué versión esté actualizando. Hay algunas cosas que debe tener en cuenta al planificar esto, como los cambios esenciales entre las versiones de RDBMS, así como las pruebas detalladas que deben liderar cualquier proceso de actualización. Esto es especialmente crítico si desea mantener la disponibilidad durante la actualización.
Actualizar a una nueva versión principal implica un riesgo y es importante planificar todo el proceso cuidadosamente. En este documento, veremos los nuevos cambios importantes en la versión 10.3 (y la próxima 10.4) y le mostraremos cómo planificar el proceso de prueba.
Para minimizar el riesgo, echemos un vistazo a las diferencias y limitaciones de la plataforma.
Comenzando con la configuración, hay algunos parámetros que tienen diferentes valores predeterminados. MariaDB proporciona una matriz de diferencias de parámetros. Se puede encontrar aquí.
En MySQL 8.0, caching_sha2_password es el complemento de autenticación predeterminado. Esta mejora debería mejorar la seguridad mediante el uso del algoritmo SHA-256. MySQL tiene este complemento habilitado de forma predeterminada, mientras que MariaDB no. Aunque ya hay una solicitud de función abierta con MariaDB MDEV-9804. MariaDB ofrece el complemento ed25519 en su lugar, que parece ser una buena alternativa al antiguo método de autenticación.
El soporte de MariaDB para el cifrado en tablas y espacios de tabla se agregó en la versión 10.1.3. Con sus tablas encriptadas, es casi imposible que alguien robe sus datos. Este tipo de encriptación también permite que su organización cumpla con las regulaciones gubernamentales como GDPR.
MariaDB admite grupos de subprocesos de conexión, que son más efectivos en situaciones en las que las consultas son relativamente cortas y la carga está limitada por la CPU. En la edición comunitaria de MySQL, la cantidad de subprocesos es estática, lo que limita la flexibilidad en estas situaciones. El plan empresarial de MySQL incluye capacidades de subprocesos.
MySQL 8.0 incluye el esquema sys, un conjunto de objetos que ayuda a los administradores de bases de datos y a los ingenieros de software a interpretar los datos recopilados por el esquema de rendimiento. Los objetos de esquema Sys se pueden utilizar para casos de uso de optimización y diagnóstico. MariaDB no tiene esta mejora incluida.
Otro son las columnas invisibles. Las columnas invisibles brindan la flexibilidad de agregar columnas a las tablas existentes sin temor a romper una aplicación. Esta característica no está disponible en MySQL. Permite crear columnas que no se enumeran en los resultados de una declaración SELECT *, ni necesitan que se les asigne un valor en una declaración INSERT cuando su nombre no se menciona en la declaración.
MariaDB decidió no implementar el soporte nativo de JSON (una de las principales características de MySQL 5.7 y 8.0) ya que afirman que no es parte del estándar SQL. En cambio, para admitir la replicación desde MySQL, solo definieron un alias para JSON, que en realidad es una columna LONGTEXT. Para garantizar que se inserte un documento JSON válido, la función JSON_VALID se puede usar como una restricción CHECK (predeterminada para MariaDB 10.4.3). MariaDB no puede acceder directamente al formato MySQL JSON.
Oracle automatiza muchas tareas con MySQL Shell. Además de SQL, MySQL Shell también ofrece capacidades de secuencias de comandos para JavaScript y Python.
Proceso de migración usando mysqldump
Una vez que conocemos nuestras limitaciones, el proceso de instalación es bastante simple. Está bastante relacionado con la instalación e importación estándar usando mysqldump. La herramienta de respaldo de MySQL Enterprise no es compatible con MariaDB, por lo que la forma recomendada es usar mysqldump. Este es el proceso de ejemplo realizado en Centos 7 y MariaDB 10.3.
Crear volcado en el servidor MySQL Enterprise
$ mysqldump --routines --events --triggers --single-transaction db1 > export_db1.sqlLimpiar el índice de caché de yum
sudo yum makecache fastInstale MariaDB 10.3
sudo yum -y install MariaDB-server MariaDB-clientInicie el servicio MariaDB.
sudo systemctl start mariadb
sudo systemctl enable mariadbProteja MariaDB ejecutando mysql_secure_installation.
# mysql_secure_installation
NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MariaDB
SERVERS IN PRODUCTION USE! PLEASE READ EACH STEP CAREFULLY!
In order to log into MariaDB to secure it, we'll need the current
password for the root user. If you've just installed MariaDB, and
you haven't set the root password yet, the password will be blank,
so you should just press enter here.
Enter current password for root (enter for none):
OK, successfully used password, moving on...
Setting the root password ensures that nobody can log into the MariaDB
root user without the proper authorisation.
Set root password? [Y/n] y
New password:
Re-enter new password:
Password updated successfully!
Reloading privilege tables..
... Success!
By default, a MariaDB installation has an anonymous user, allowing anyone
to log into MariaDB without having to have a user account created for
them. This is intended only for testing, and to make the installation
go a bit smoother. You should remove them before moving into a
production environment.
Remove anonymous users? [Y/n] y
... Success!
Normally, root should only be allowed to connect from 'localhost'. This
ensures that someone cannot guess at the root password from the network.
Disallow root login remotely? [Y/n] y
... Success!
By default, MariaDB comes with a database named 'test' that anyone can
access. This is also intended only for testing, and should be removed
before moving into a production environment.
Remove test database and access to it? [Y/n] y
- Dropping test database...
... Success!
- Removing privileges on test database...
... Success!
Reloading the privilege tables will ensure that all changes made so far
will take effect immediately.
Reload privilege tables now? [Y/n] y
... Success!
Cleaning up...
All done! If you've completed all of the above steps, your MariaDB
installation should now be secure.
Thanks for using MariaDB!Volcado de importación
Mysql -uroot -p
> tee import.log
> source export_db1.sql
Review the import log.
$vi import.logPara implementar un entorno, también puede usar ClusterControl, que tiene una opción para implementar desde cero.
ClusterControl Implementar MariaDB ClusterControl también se puede utilizar para configurar la replicación o para importar una copia de seguridad desde MySQL Enterprise Edition.
Proceso de migración mediante replicación
El otro enfoque para la migración entre MySQL Enterprise y MariaDB es utilizar el proceso de replicación. Las versiones de MariaDB permiten replicarlas desde bases de datos MySQL, lo que significa que puede migrar fácilmente bases de datos MySQL a MariaDB. Las versiones de MySQL Enterprise no permitirán la replicación desde servidores MariaDB, por lo que esta es una ruta unidireccional.
Basado en la documentación de MariaDB:https://mariadb.com/kb/en/library/mariadb-vs- compatibilidad mysql/. X hace referencia a la documentación de MySQL.Recursos relacionados ClusterControl for MariaDB Novedades de MariaDB 10.4 Cómo administrar MySQL - para Oracle DBA Aquí hay algunas reglas generales señaladas por MariaDB.
- La replicación de MySQL 5.5 a MariaDB 5.5+ debería funcionar. Querrá que MariaDB sea una versión igual o superior a su servidor MySQL.
- Al usar MariaDB 10.2+ como esclavo, puede ser necesario establecer binlog_checksum en NINGUNO.
- La replicación de MySQL 5.6 sin GTID a MariaDB 10+ debería funcionar.
- La replicación de MySQL 5.6 con GTID, binlog_rows_query_log_events y eventos ignorables funciona a partir de MariaDB 10.0.22 y MariaDB 10.1.8. En este caso, MariaDB eliminará los GTID de MySQL y otros eventos innecesarios y, en su lugar, agregará sus propios GTID.
Incluso si no planea usar la replicación en el proceso de migración/transferencia, tener una es un buen generador de confianza para replicar su servidor de producción en un espacio aislado de prueba y luego practicar en él.
Esperamos que esta publicación introductoria del blog lo haya ayudado a comprender el proceso de evaluación e implementación de la migración de MySQL Enterprise a MariaDB.
