Gartner prévoit que d'ici 2022, 50 % des bases de données commerciales existantes auront été converties en bases de données open source. Plus encore, 70 % des nouvelles applications internes seront développées sur une plate-forme de base de données open source (State of the Open-Source DBMS Market, 2018).
Ce sont des chiffres élevés compte tenu de la maturité, de la stabilité et de la criticité des logiciels de base de données propriétaires populaires. La même chose peut être observée dans le classement des meilleures bases de données, où la plupart des dix premières bases de données sont open source.
https://db-engines.com/fr/classementQu'est-ce qui pousse les entreprises à agir ainsi ?
Il peut y avoir de nombreuses raisons de migrer les systèmes de base de données. Pour certains, la principale raison sera le coût de la licence et de la propriété; mais est-ce vraiment une question de coût? Et l'open source est-il suffisamment stable pour déplacer les systèmes de production critiques vers ce nouveau monde open source ?
Les bases de données open source, en particulier les nouvelles introduites dans une organisation, proviennent souvent d'un développeur faisant partie d'une équipe de projet. Il est choisi car il est gratuit (n'impacte pas les dépenses externes directes du projet) et répond aux exigences techniques du moment.
Mais l'aspect gratuit n'est pas simplement gratuit, car vous devez tenir compte de nombreux facteurs, notamment la migration et le coût des heures de travail. Plus la migration est fluide, moins vous consacrez de temps et d'argent au projet.
Les migrations de bases de données peuvent être difficiles, en particulier pour les migrations de bases de données propriétaires hétérogènes telles qu'Oracle vers PostgreSQL, Oracle vers Percona ou MySQL. La structure complexe du schéma, les types de données et le code de base de données comme PL/SQL peuvent être très différents de ceux des bases de données cibles,
nécessitant une étape de transformation du schéma et du code avant le début de la migration des données.
Dans le récent article de mon collègue Paul Namuag, il a examiné comment migrer Oracle vers Percona.
Cette fois, nous allons examiner ce que vous devez savoir avant de migrer d'Oracle vers MariaDB.
MariaDB promet les fonctionnalités d'entreprise et les fonctionnalités de migration qui peuvent aider à migrer les bases de données Oracle vers le monde open source.
Dans cet article de blog, nous aborderons les points suivants :
- Pourquoi migrer ?
- Différences entre les moteurs de stockage
- Considérations relatives à la connectivité de la base de données
- Simplicité d'installation et d'administration
- Différences de sécurité
- Réplication et haute disponibilité
- PL/SQL et code de base de données
- Clustering et mise à l'échelle
- Sauvegarde et restauration
- Compatibilité cloud
- Considérations diverses
Pourquoi migrer depuis Oracle ?
La plupart des entreprises utiliseront Oracle ou SQL Server, ou une combinaison des deux, avec de petites poches de bases de données open source isolées fonctionnant indépendamment. Les petites et moyennes entreprises auraient tendance à déployer principalement des bases de données open source, en particulier pour les nouvelles applications. Mais cela est en train de changer, et souvent, l'open source est le choix principal, même pour les grandes organisations.
Une comparaison rapide de ces deux systèmes de bases de données se présente comme suit :
- Seule Oracle Express Edition est gratuite, mais ses fonctionnalités sont très limitées par rapport à MariaDB. Pour des fonctionnalités étendues, vous devez acheter Oracle Standard Edition ou Oracle Enterprise Edition.
- D'un autre côté, MariaDB et la communauté MySQL travaillaient dur pour minimiser l'écart potentiel de fonctionnalités. La conformité en matière de sécurité, les sauvegardes à chaud et de nombreuses autres fonctionnalités d'entreprise sont désormais disponibles dans MariaDB.
Il y a des choses qui ont toujours été plus flexibles dans MariaDB/MySQL que dans les configurations massives d'Oracle. L'un d'eux est la facilité de réplication et l'évolutivité horizontale du cluster.
Différences entre les moteurs de stockage
Tout d'abord, commençons par quelques bases. Vous pouvez encore entendre beaucoup de légendes et de mythes concernant les limitations de MySQL ou MariaDB, qui font principalement référence aux temps sombres où le moteur de stockage principal était MyISAM.
MyISAM était le moteur de stockage par défaut de MySQL 3.23 jusqu'à ce qu'il soit remplacé par InnoDB dans MariaDB 5.5. C'est un moteur léger, non transactionnel, avec d'excellentes performances, mais qui n'offre pas le verrouillage au niveau des lignes ni la fiabilité d'InnoDB.
Avec InnoDB (moteur de stockage par défaut), MariaDB propose les deux verrous standard au niveau de la ligne, qui sont les verrous partagés (S) et les verrous exclusifs (X). Un verrou partagé est obtenu pour lire une ligne et permet à d'autres transactions de lire la ligne verrouillée. Différentes transactions peuvent également acquérir leurs propres verrous partagés.
Le verrou particulier est obtenu pour écrire sur une ligne et empêche des transactions supplémentaires de verrouiller la même ligne.
InnoDB a définitivement couvert le plus grand écart de fonctionnalités transactionnelles entre ces deux systèmes.
En raison de la nature enfichable de MariaDB, elle offre encore plus de moteurs de stockage afin que vous puissiez mieux l'adapter à une charge de travail spécifique. C'est à dire. lorsque l'espace compte, vous pouvez opter pour TokuDB qui offre un excellent taux de compression, Spider optimisé pour le partitionnement et le partage de données, ColumnStore pour la mise à l'échelle du Big Data.
Néanmoins, pour ceux qui migrent d'Oracle, ma recommandation serait d'utiliser d'abord le moteur de stockage InnoDB.
Considérations relatives à la connectivité
MariaDB partage avec Oracle un bon support pour l'accès aux bases de données, y compris les pilotes ODBC et JDBC, ainsi que les bibliothèques d'accès pour Perl, Python et PHP. MySQL et Oracle prennent tous deux en charge les grands objets binaires, les types de données caractère, numérique et date. Vous ne devriez donc avoir aucun problème à trouver le bon connecteur pour vos services applicatifs.
MariaDB n'a pas le processus d'écoute dédié pour maintenir les connexions de base de données ni l'adresse SCAN pour la base de données en cluster comme nous le savons d'Oracle. Vous ne trouverez pas non plus de services de base de données flexibles. Au lieu de cela, vous devrez configurer manuellement entre le socket Unix (un moyen local et le plus sécurisé de connecter DB - application sur le même serveur), les connexions distantes (par défaut, MariaDB n'autorise pas les connexions distantes) et également le canal et la mémoire disponible sur Windows systèmes uniquement. Pour le cluster, l'adresse SCAN doit être remplacée par l'équilibreur de charge. MariaDB recommande d'utiliser leur autre produit MaxScale, mais vous pouvez également en trouver d'autres comme ProxySQL ou HAproxy qui fonctionneront avec MariaDB, avec certaines limitations. Bien que l'utilisation d'équilibreurs de charge externes pour MariaDB puisse être difficile, vous pouvez trouver des fonctionnalités intéressantes qui, à titre de comparaison, ne sont pas disponibles dans la base de données Oracle.
Un équilibreur de charge serait également une recommandation pour ceux qui recherchent Oracle Transparent Application Failover (TAF), Oracle Firewall DB ou certaines des fonctionnalités de sécurité avancées comme Oracle Connection Manager. Vous trouverez plus d'informations sur le choix du bon équilibreur de charge dans le livre blanc suivant.
Bien que ces technologies soient gratuites et puissent être déployées manuellement à l'aide d'installations basées sur des scripts, des systèmes tels que ClusterControl automatisent le processus avec leur interface pointer-cliquer. ClusterControl vous permet également de déployer des technologies de mise en cache.
Simplicité d'installation et d'administration
La dernière version disponible d'Oracle DB a ajouté une fonctionnalité d'installation tant attendue :Oracle 18c peut désormais être installé sur Oracle Linux à l'aide d'un RPM. L'installation dédiée basée sur Java a toujours été un problème pour ceux qui voulaient écrire une automatisation pour leurs livres de recettes ou des extraits de code Puppet. Vous pouviez opter pour une installation silencieuse prédéfinie, mais le fichier changeait de temps en temps et vous deviez toujours faire face à l'enfer des dépendances. L'installation basée sur RPM était définitivement une bonne décision.
Alors, comment ça marche dans MariaDB ?
Pour ceux qui quittent le monde Oracle, c'est toujours une bonne surprise de voir à quelle vitesse vous pouvez déployer des instances, créer de nouvelles bases de données ou même mettre en place des flux de réplication complexes. Le processus d'installation et de configuration est probablement la partie la plus fluide du processus de migration. Bien que choisir les bons paramètres demande du temps et des connaissances.
Oracle fournit un ensemble de distributions binaires de MySQL. Ceux-ci incluent des distributions binaires génériques sous la forme de fichiers tar compressés (fichiers avec une extension .tar.gz) pour un certain nombre de plates-formes et de binaires dans des packages spécifiques à la plate-forme. Sur la plate-forme Windows, vous pouvez trouver un assistant d'installation standard via une interface graphique.
L'assistant de configuration de base de données Oracle (DBCA) n'est fondamentalement pas nécessaire car vous pourrez créer une base de données avec une seule commande de ligne.
CREATE [OR REPLACE] {DATABASE | SCHEMA} [IF NOT EXISTS] db_name
[create_specification] ...
create_specification:
[DEFAULT] CHARACTER SET [=] charset_name
| [DEFAULT] COLLATE [=] collation_name
Vous pouvez également avoir une base de données avec différents classements de base de données et jeux de caractères sous la même instance MariaDB.
La configuration de la réplication consiste simplement à activer la journalisation binaire sur un maître (similaire au journal d'archivage dans Oracle) et à exécuter la commande suivante sur l'esclave pour l'attacher au maître.
CHANGE MASTER TO
MASTER_HOST = host,
MASTER_PORT = port,
MASTER_USER = replication_user,
MASTER_PASSWORD = password,
MASTER_AUTO_POSITION = 1;
Sécurité et conformité
Oracle fournit une sécurité de base de données améliorée.
L'authentification de l'utilisateur est effectuée dans Oracle en spécifiant des rôles globaux en plus de l'emplacement, du nom d'utilisateur et du mot de passe. Dans Oracle, l'authentification de l'utilisateur est effectuée par différentes méthodes d'authentification, notamment l'authentification de base de données, l'authentification externe et l'authentification proxy.
Pendant longtemps, les rôles n'étaient pas disponibles dans MariaDB ou MySQL. MariaDB a ajouté des rôles avec la version 10.2 après leur apparition dans MySQL 8.0.
Les rôles, une option largement utilisée dans les configurations de base de données Oracle courantes, peuvent être facilement transformés dans MariaDB, vous n'avez donc pas à perdre de temps sur les ajustements des autorisations d'un seul utilisateur.
Créer, modifier l'utilisateur, les mots de passe :tout fonctionne de la même manière qu'Oracle DB.
Pour respecter les normes de conformité en matière de sécurité d'entreprise, MariaDB propose des fonctionnalités intégrées telles que :
- Plug-in d'audit dans
- Chiffrement des données au repos
- Certificats, connexion TSS
- Plug-in PAM
Offres de plugins d'audit une sorte d'audit à grain fin (FGA) ou AUDI SQL disponible dans Oracle. Il n'offre pas le même ensemble de fonctionnalités, mais il est généralement suffisant pour satisfaire les audits de conformité de sécurité.
Chiffrement des données au repos Le chiffrement des données au repos peut être une exigence pour les réglementations de sécurité telles que HIPAA ou PCI DSS. Un tel cryptage peut être mis en œuvre à plusieurs niveaux - vous pouvez crypter l'intégralité du disque sur lequel les fichiers sont stockés. Vous pouvez chiffrer uniquement la base de données MySQL grâce aux fonctionnalités disponibles dans les dernières versions de MySQL ou MariaDB. Le cryptage peut également être implémenté dans l'application afin qu'elle crypte les données avant de les stocker dans la base de données. Chaque option a ses avantages et ses inconvénients :le chiffrement de disque ne peut être utile que lorsque les disques sont physiquement volés, mais les fichiers ne seraient pas chiffrés sur un serveur de base de données en cours d'exécution.
Plug-in PAM étend la fonctionnalité de journalisation aux comptes d'utilisateurs restreints avec des paramètres LDAP. En fait, je trouve qu'il est beaucoup plus facile à configurer que l'intégration LDAP avec Oracle Database.
Réplication et haute disponibilité
MariaDB est bien connue pour sa simplicité de réplication et sa flexibilité. Par défaut, vous pouvez lire ou même écrire sur vos serveurs de secours/esclaves. Heureusement, les versions de MySQL 10.X ont apporté de nombreuses améliorations significatives à la réplication, notamment les ID de transaction globale, les sommes de contrôle d'événements, les esclaves multithreads et les esclaves/maîtres anti-crash pour rendre la réplication encore meilleure. Les DBA habitués aux lectures et écritures de réplication MySQL s'attendraient à une solution similaire ou même plus simple de son grand frère, Oracle. Malheureusement pas par défaut.
L'implémentation de secours physique standard pour Oracle est fermée pour toute opération de lecture-écriture. En fait, Oracle propose une variation logique, mais il a de nombreuses limitations et n'est pas conçu pour la haute disponibilité. La solution à ce problème est une fonctionnalité payante supplémentaire appelée Active Data Guard, que vous pouvez utiliser pour lire les données de la veille pendant que vous appliquez les journaux redo.
Active Data Guard est une solution complémentaire payante du logiciel gratuit de récupération après sinistre Data Guard d'Oracle disponible uniquement pour Oracle Database Enterprise Edition (licence la plus coûteuse). Il offre un accès en lecture seule, tout en appliquant en continu les modifications envoyées depuis la base de données principale. En tant que base de données de secours active, elle permet de décharger les requêtes de lecture, les rapports et les sauvegardes incrémentielles de la base de données principale. L'architecture du produit est conçue pour permettre aux bases de données de secours d'être isolées des pannes pouvant survenir au niveau de la base de données primaire.
Une fonctionnalité intéressante de la base de données Oracle 12c et quelque chose qui manquerait à Oracle DBA est la validation de la corruption des données. Des contrôles de corruption Oracle Data Guard sont effectués pour s'assurer que les données sont parfaitement alignées avant qu'elles ne soient copiées dans une base de données de secours. Ce mécanisme peut également être utilisé pour restaurer des blocs de données sur le primaire directement à partir de la base de données de secours.
MariaDB propose diverses méthodes de réplication et fonctionnalités de réplication telles que :
- synchrone,
- asynchrone,
- semi-synchrone
L'ensemble de fonctionnalités pour la réplication MariaDB est riche. Avec la réplication synchrone, vous pouvez configurer le basculement sans perte de transaction en écriture. Pour réduire les délais de réplication asynchrone, vous souhaiterez peut-être utiliser la réplication parallélisée dans l'ordre sur les esclaves. Les événements qui peuvent être compressés sont les événements qui peuvent normalement avoir une taille importante :les événements de requête (pour DDL et DML dans la réplication basée sur les instructions) et les événements de ligne (pour DML dans la réplication basée sur les lignes). Semblable à d'autres options de compression, la réplication compressée MariaDB est transparente. Comme mentionné précédemment, l'ensemble du processus est très simple par rapport à la réplication physique et logique d'Oracle Data Guard.
PL/SQL et code de base de données
Passons maintenant à la partie la plus difficile :PL/SQL.
Alors que la réplication et la haute disponibilité avec MariaDB règnent en maîtres. Oracle est le roi du PL/SQL, sans aucun doute là-bas.
PL/SQL est le principal obstacle à la migration vers le monde open source dans de nombreuses organisations . Mais MariaDB n'abandonne pas ici.
MariaDB 10.3 (également connue sous le nom de MariaDB TX 3.0) a ajouté de nouvelles fonctionnalités étonnantes, notamment des constructions SEQUENCE, des packages de style Oracle et le type de données ROW, ce qui facilite grandement les migrations.
Avec le nouveau paramètre SQL_MODE =ORACLE, MariaDB est désormais capable d'analyser, selon le cas, un tas d'anciens Oracle PL/SQL sans réécrire le code.
Comme nous pouvons le constater sur leur page de témoignage client en utilisant la compatibilité Oracle PL/SQL de base dans MariaDB TX 3.0, la Development Bank of Singapore (DBS) a été en mesure de migrer plus de la moitié de ses applications critiques en seulement 12 mois à partir d'Oracle Base de données vers MariaDB.
Le nouveau mode de compatibilité aide avec la syntaxe suivante :
- Syntaxe de boucle
- Déclaration de variables
- Construction de procédure stockée non-ANSI
- Syntaxe du curseur
- Paramètres de procédure stockée
- Héritage des types de données (%TYPE, %ROWTYPE)
- Exceptions de style PL/SQL
- Synonymes des types SQL de base (VARCHAR2, NUMBER, …)
Mais si nous jetons un coup d'œil à l'ancienne version 10.2, une partie de la compatibilité entre Oracle et MariaDB est apparue auparavant comme :
- Expressions de table courantes
- Requêtes SQL récursives
- Fonctions Windows, NTILETE, RANK, DENESE_RANK.
L'analyse PL/SQL native ou, dans certains cas, l'exécution directe de procédures Oracle natives peuvent réduire considérablement le coût de développement.
Une autre fonctionnalité très utile ajoutée par SQL_MODE=Oracle est les séquences. L'implémentation des séquences dans MariaDB Server 10.3 suit la norme SQL:2003 et inclut la compatibilité syntaxique avec Oracle.
Pour créer une séquence, une instruction create est utilisée :
CREATE SEQUENCE Sequence_1
START WITH 1
INCREMENT BY 1;
Une fois créées, les séquences peuvent être utilisées par exemple avec des inserts comme :
INSERT INTO database (database_id, database_name) VALUES(Sequence_1.NEXTVAL, 'MariaDB');
Clustering et mise à l'échelle
MariaDB est un cluster de base de données asynchrone, actif-actif et multimaître.
Le cluster MariaDB diffère de ce que l'on appelle le cluster MySQL d'Oracle - NDB.
Le cluster MariaDB est basé sur le plugin de réplication multi-maître fourni par Codership (Galera). Depuis la version 5.5, la technologie Galera (API wsrep) fait partie intégrante de MariaDB. L'architecture du plug-in Galera repose sur trois couches principales :certification, réplication et cadre de communication de groupe.
La couche de certification prépare les ensembles d'écriture et effectue les vérifications de certification sur eux, garantissant qu'ils peuvent être appliqués.
La couche de réplication gère le protocole de réplication et fournit la capacité de commande totale.
Group Communication Framework implémente une architecture de plug-in qui permet à d'autres systèmes de se connecter via le schéma backend gcomm.
La principale différence avec Oracle RAC est que chaque nœud a des données séparées. Oracle RAC est souvent confondu avec une solution HA complémentaire alors que les disques se trouvent généralement dans la même baie de disques. MariaDB offre non seulement un stockage redondant, mais prend également en charge le clustering géolocalisé sans avoir besoin de fibre dédiée.
Sauvegarde et restauration
Oracle propose de nombreux mécanismes de sauvegarde, notamment la sauvegarde à chaud, la sauvegarde, l'importation, l'exportation et bien d'autres.
Contrairement à MySQL, MariaDB propose un outil externe pour les sauvegardes à chaud appelé mariabackup. Il s'agit d'un fork de Percona XtraBackup conçu pour fonctionner avec des tables cryptées et compressées et constitue la méthode de sauvegarde recommandée pour les bases de données MariaDB.
MariaDB Server 10.1 a introduit la compression MariaDB et le chiffrement des données au repos, mais les solutions de sauvegarde existantes ne prenaient pas en charge la capacité de sauvegarde complète pour ces fonctionnalités. MariaDB a donc décidé d'étendre XtraBackup (version 2.3.8) et a nommé cette solution Mariabackup.
Percona et Mariabackup offrent des fonctionnalités similaires, mais si vous êtes intéressé par les différences, vous pouvez les trouver ici.
Ce que MariaDB ne propose pas, c'est le catalogue de récupération de vos sauvegardes de base de données. Heureusement, cela peut être étendu avec des systèmes tiers comme ClusterControl.
Compatibilité cloud
Les infrastructures cloud sont de plus en plus populaires de nos jours. Bien qu'une machine virtuelle cloud ne soit pas aussi fiable qu'un serveur d'entreprise, les principaux fournisseurs de cloud offrent une variété d'outils pour augmenter la disponibilité des services. Vous pouvez choisir entre l'architecture EC2 ou DBaaS comme Amazon RDS.
Amazon RDS prend en charge MariaDB Server 10.3. Il ne prend pas en charge SQL_MODE=Oracle mais vous pouvez toujours trouver un ensemble de fonctionnalités facilitant la migration. Le cloud Amazon prend en charge les tâches de gestion courantes telles que la surveillance, les sauvegardes, les déploiements multi-AZ, etc.
Un autre fournisseur de cloud populaire, Google Cloud, propose également la version la plus récente de MariaDB. Vous pouvez le déployer en tant qu'image de VM certifiée conteneur ou bibliothèque Bintami.
Azure propose également sa propre implémentation de MariaDB. Il est similaire à Amazon RDS, avec les sauvegardes, la mise à l'échelle et les builds en haute disponibilité. Le SLA garanti est de 99,99 %, ce qui correspond à 4 m 23 secondes par mois d'indisponibilité.
Considérations diverses
Comme mentionné au tout début de cet article, la migration d'Oracle vers MariaDB est un processus en plusieurs étapes. Un conseil général sera de ne pas essayer de migrer toutes les bases de données à la fois. Diviser la migration en petits lots est, dans la plupart des scénarios, la meilleure approche.
Si vous n'êtes pas familier avec la technologie, essayez-la. Vous devez vous sentir en confiance avec la plate-forme et connaître ses avantages et ses inconvénients. Les tests renforcent la confiance et affectent vos décisions en matière de migration.
Il existe des outils intéressants qui peuvent vous aider dans le processus de migration PL/SQL le plus difficile. Les plus intéressants sont dbconvert, AWS Schema Conversion Tool - AWS Documentation.
Au fil des ans, MariaDB a acquis un support et une maturité d'entreprise pour exécuter des systèmes de transaction de données critiques et complexes. Avec la version récente, MariaDB a ajouté de nouvelles fonctionnalités intéressantes telles que la compatibilité SQL_Mode=Oracle, rendant le processus de transition plus facile que jamais.
Enfin, vous pouvez me rejoindre le 12 mars pour un webinaire au cours duquel je vous expliquerai tout ce que vous devez savoir sur la migration d'une base de données Oracle vers MariaDB.