MariaDB
 sql >> Base de données >  >> RDS >> MariaDB

Comparaison de la haute disponibilité des bases de données - Réplication MySQL / MariaDB vs Oracle Data Guard

Dans « State of the Open-Source DBMS Market, 2018 », Gartner prédit que d'ici 2022, 70 % des nouvelles applications internes seront développées sur une base de données open-source. Et 50% des bases de données commerciales existantes seront converties. Alors, DBA Oracle, préparez-vous à commencer à déployer et à gérer de nouvelles bases de données open source, ainsi que vos anciennes instances Oracle. Sauf si vous le faites déjà.

Alors, comment la réplication MySQL ou MariaDB se compare-t-elle à Oracle Data Guard ? Dans ce blog, nous comparerons les deux du point de vue d'une solution de base de données à haute disponibilité.

Ce qu'il faut rechercher

Une architecture de réplication de données moderne repose sur des conceptions flexibles qui permettent une réplication de données unidirectionnelle et bidirectionnelle, ainsi qu'un basculement rapide et automatisé vers des bases de données secondaires en cas d'interruption de service imprévue. Le basculement doit également être facile à exécuter et fiable afin qu'aucune transaction validée ne soit perdue. De plus, le basculement ou le basculement doit idéalement être transparent pour les applications.

Les solutions de réplication de données doivent être capables de copier les données avec une très faible latence pour éviter les goulots d'étranglement de traitement et garantir un accès en temps réel aux données. Des copies en temps réel pourraient être déployées sur une autre base de données exécutée sur du matériel peu coûteux.

Lorsqu'il est utilisé pour la reprise après sinistre, le système doit être validé pour garantir l'accès des applications au système secondaire avec une interruption de service minimale. La solution idéale doit permettre de tester régulièrement le processus de reprise après sinistre.

Principaux sujets de comparaison

  • Disponibilité et cohérence des données
    • Gtid, scm
    • Mentionnez la réplication vers plusieurs modèles de secours, asynchrones + synchronisés
    • Isolation de la veille des défauts de production (par exemple, réplication retardée pour mysql)
    • Éviter la perte de données (synchronisation de la réplication)
  • Utilisation des systèmes de secours
    • Utilisation de la veille
  • Basculement, basculement et récupération automatique
    • Basculement de base de données
    • Basculement d'application transparent (TAF vs ProxySQL, MaxScale)
  • Sécurité
  • Facilité d'utilisation et de gestion (gestion unifiée des composants pré-intégrés)

Disponibilité et cohérence des données

ID GTID MySQL

La réplication de MySQL 5.5 était basée sur des événements de journal binaire, où tout ce qu'un esclave savait était l'événement précis et la position exacte qu'il venait de lire du maître. Toute transaction unique d'un maître peut s'être terminée dans divers journaux binaires de différents esclaves, et la transaction aurait généralement des positions différentes dans ces journaux. C'était une solution simple qui comportait des limitations, les changements de topologie pouvant nécessiter qu'un administrateur arrête la réplication sur les instances concernées. Ces changements pourraient causer d'autres problèmes, par exemple, un esclave ne pourrait pas être déplacé vers le bas de la chaîne de réplication sans une reconstruction fastidieuse. La réparation d'un lien de réplication rompu nécessiterait de déterminer manuellement un nouveau fichier journal binaire et la position de la dernière transaction exécutée sur l'esclave et de reprendre à partir de là, ou une reconstruction totale. Nous avons tous dû contourner ces limitations tout en rêvant d'un identifiant de transaction global.

MySQL version 5.6 (et MariaDB version 10.0.2) a introduit un mécanisme pour résoudre ce problème. GTID (Global Transaction Identifier) ​​fournit un meilleur mappage des transactions entre les nœuds.

Avec GTID, les esclaves peuvent voir une transaction unique provenant de plusieurs maîtres et cela peut facilement être mappé dans la liste d'exécution des esclaves s'il doit redémarrer ou reprendre la réplication. Donc, le conseil est de toujours utiliser GTID. Notez que MySQL et MariaDB ont des implémentations GTID différentes.

SCN Oracle

En 1992, avec la version 7.3, Oracle a introduit une solution pour conserver une copie synchronisée d'une base de données en veille, connue sous le nom de Data Guard à partir de la version 9i version 2. Une configuration Data Guard se compose de deux composants principaux, une seule base de données principale et une base de données de secours. (Jusqu'à 30). Les modifications apportées à la base de données principale sont transmises via la base de données de secours, et ces modifications sont appliquées à la base de données de secours pour la maintenir synchronisée.

Oracle Data Guard est initialement créé à partir d'une sauvegarde de la base de données principale. Data Guard synchronise automatiquement la base de données principale et toutes les bases de données de secours en transmettant le rétablissement de la base de données principale - les informations utilisées par chaque base de données Oracle pour protéger les transactions - et en les appliquant à la base de données de secours. Oracle utilise un mécanisme interne appelé SCN (System Change Number). Le numéro de changement de système (SCN) est l'horloge d'Oracle, chaque fois que nous nous engageons, l'horloge s'incrémente. Le SCN marque un point cohérent dans le temps dans la base de données qui est un point de contrôle qui consiste à écrire des blocs modifiés (blocs modifiés du cache tampon sur le disque). Nous pouvons le comparer à GTID dans MySQL.

Les services de transport Data Guard gèrent tous les aspects de la transmission de restauration d'une base de données principale à une base de données de secours. Au fur et à mesure que les utilisateurs valident des transactions sur le serveur principal, des enregistrements redo sont générés et écrits dans un fichier journal en ligne local. Les services de transport Data Guard transmettent simultanément le même fichier redo directement depuis le tampon de journalisation de la base de données principale (mémoire allouée dans la zone globale du système) vers la ou les bases de données de secours où il est écrit dans un fichier de journalisation de secours.

Il existe quelques différences principales entre la réplication MySQL et Data Guard. La transmission directe de Data Guard à partir de la mémoire évite la surcharge d'E/S disque sur la base de données principale. C'est différent du fonctionnement de MySQL - la lecture de données à partir de la mémoire diminue les E/S sur une base de données primaire.

Data Guard ne transmet que la restauration de la base de données. Cela contraste fortement avec la mise en miroir à distance du stockage qui doit transmettre chaque bloc modifié dans chaque fichier pour maintenir la synchronisation en temps réel.

Modèles asynchrones + synchrones

Oracle Data Guard propose trois modèles différents pour l'application de rétablissement. Modèles adaptatifs en fonction du matériel disponible, des processus et, en fin de compte, des besoins de l'entreprise.

  • Performances maximales :mode de fonctionnement par défaut, permettant à une transaction de s'engager dès que les données de rétablissement nécessaires pour récupérer cette transaction sont écrites dans le journal de rétablissement local sur le maître.
  • Protection maximale :aucune perte de données et niveau de protection maximal. Les données de rétablissement nécessaires pour améliorer chaque opération doivent être écrites à la fois dans le journal de rétablissement en ligne local sur le maître et dans le journal de rétablissement de secours sur au moins une base de données de secours avant la validation de la transaction (Oracle recommande au moins deux serveurs de secours). La base de données principale s'arrêtera si une erreur l'empêche d'écrire son flux de rétablissement dans au moins une base de données de secours synchronisée.
  • Disponibilité maximale :similaire à la protection maximale, mais la base de données principale ne s'arrêtera pas si une erreur l'empêche d'écrire son flux de rétablissement.

Lorsqu'il s'agit de choisir votre configuration de réplication MySQL, vous avez le choix entre la réplication asynchrone ou la réplication semi-synchrone.

  • L'application binlog asynchrone est la méthode par défaut pour la réplication MySQL. Le maître écrit les événements dans son journal binaire et les esclaves les demandent lorsqu'ils sont prêts. Il n'y a aucune garantie que n'importe quel événement atteindra jamais n'importe quel esclave.
  • La validation semi-synchrone sur le primaire est retardée jusqu'à ce que le maître reçoive un accusé de réception de l'esclave semi-synchrone indiquant que les données sont reçues et écrites par l'esclave. Veuillez noter que la réplication semi-synchrone nécessite l'installation d'un plug-in supplémentaire.

Utilisation des systèmes de secours

MySQL est bien connu 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, MySQL 5.6 et 5.7 ont apporté de nombreuses améliorations significatives à la réplication, notamment les identifiants de transaction globaux, les sommes de contrôle d'événements, les esclaves multithread et les esclaves/maîtres anti-crash pour le rendre encore meilleur. 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.

Basculement, basculement et récupération automatique

Pour que votre configuration de réplication reste stable et fonctionne, il est essentiel que le système soit résistant aux pannes. Les échecs sont causés par des bogues logiciels, des problèmes de configuration ou des problèmes matériels, et peuvent survenir à tout moment. En cas de panne d'un serveur, vous avez besoin d'une notification d'alarme concernant la configuration dégradée. Le basculement (promotion d'un esclave en maître) peut être effectué par l'administrateur, qui doit décider quel esclave promouvoir.

L'administrateur a besoin d'informations sur l'échec, l'état de la synchronisation au cas où des données seraient perdues et enfin, les étapes pour effectuer l'action. Idéalement, tout devrait être automatisé et visible depuis une seule console.

Il existe deux approches principales pour le basculement MySQL, automatique et manuel. Les deux options ont leurs fans, nous décrivons les concepts dans un autre article.

Avec le GTID, le basculement manuel devient beaucoup plus facile. Il se compose d'étapes telles que :

  • Arrêter le module récepteur (STOP SLAVE IO_THREAD)
  • Changer de maître (CHANGER LE MAÎTRE EN )
  • Démarrer le module récepteur (START SLAVE IO_THREAD)

Oracle Data Guard est livré avec une solution de basculement/basculement dédiée :Data Guard Broker. Le courtier est une infrastructure de gestion distribuée qui automatise et centralise la création, la maintenance et la surveillance des configurations Oracle Data Guard. Avec l'accès à l'outil de courtier DG, vous pouvez effectuer des changements de configuration, des basculements, des basculements et même des tests à sec de votre configuration de haute disponibilité. Les deux actions principales sont :

  • La commande SWITCHOVER TO est utilisée pour effectuer l'opération de basculement. Une fois l'opération de basculement réussie, les instances de base de données changent de place et la réplication se poursuit. Il n'est pas possible de basculer lorsque le mode veille ne répond pas ou qu'il est en panne.
  • Le FAILOVER TO commun est utilisé pour effectuer le basculement. Après l'opération de basculement, le serveur principal précédent nécessite une recréation, mais le nouveau serveur principal peut prendre la charge de travail de la base de données.

En parlant de basculement, nous devons considérer à quel point le basculement de votre application peut être transparent. En cas de panne planifiée/non planifiée, avec quelle efficacité les sessions utilisateur peuvent-elles être dirigées vers un site secondaire, avec une interruption d'activité minimale ?

L'approche standard pour MySQL consisterait à utiliser l'un des équilibreurs de charge disponibles. À partir de HAProxy qui est largement utilisé pour le basculement HTTP ou TCP/IP vers Maxscale ou ProxySQL prenant en charge la base de données.

Dans Oracle, ce problème est résolu par TAF (Transparent Application Failover). Une fois le basculement ou le basculement effectué, l'application est automatiquement dirigée vers le nouveau serveur principal. TAF permet à l'application de se reconnecter automatiquement et de manière transparente à une nouvelle base de données, si l'instance de base de données à laquelle la connexion est établie échoue.

Sécurité

La sécurité des données est un problème brûlant pour de nombreuses organisations de nos jours. Pour ceux qui ont besoin de mettre en œuvre des normes telles que PCI DSS ou HIPAA, la sécurité des bases de données est indispensable. Les environnements croisés WAN peuvent susciter des inquiétudes concernant la confidentialité et la sécurité des données, d'autant plus que de plus en plus d'entreprises doivent se conformer aux réglementations nationales et internationales. Les journaux binaires MySQL utilisés pour la réplication peuvent contenir des données sensibles faciles à lire. Avec la configuration standard, le vol de données est un processus très simple. MySQL prend en charge SSL comme mécanisme pour crypter le trafic à la fois entre les serveurs MySQL (réplication) et entre les serveurs MySQL et les clients. Une manière typique d'implémenter le cryptage SSL consiste à utiliser des certificats auto-signés. La plupart du temps, il n'est pas nécessaire d'obtenir un certificat SSL délivré par l'autorité de certification. Vous pouvez soit utiliser openssl pour créer des certificats, exemple ci-dessous :

$ openssl genrsa 2048 > ca-key.pem
$ openssl req -new -x509 -nodes -days 3600 -key ca-key.pem > ca-cert.pem
$ openssl req -newkey rsa:2048 -days 3600 -nodes -keyout client-key.pem > client-req.pem
$ openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > client-cert.pem
$ openssl req -newkey rsa:2048 -days 3600 -nodes -keyout client-key.pem > client-req.pem
$ openssl x509 -req -in client-req.pem -days 1000 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 > client-cert.pem
$ openssl rsa -in client-key.pem -out client-key.pem
$ openssl rsa -in server-key.pem -out server-key.pem

Modifiez ensuite la réplication avec les paramètres pour SSL.

….MASTER_SSL=1, MASTER_SSL_CA = '/etc/security/ca.pem', MASTER_SSL_CERT = '/etc/security/client-cert.pem', MASTER_SSL_KEY = '/etc/security/client-key.pem';

Pour une option plus automatisée, vous pouvez utiliser ClusterControl pour activer le chiffrement et gérer les clés SSL.

Dans Oracle 12c, Data Guard redo transport peut être intégré à un ensemble de fonctionnalités de sécurité dédiées appelées Oracle Advanced Security (OAS). La sécurité avancée peut être utilisée pour activer les services de cryptage et d'authentification entre les systèmes principal et de secours. Par exemple, l'activation de l'algorithme de chiffrement AES (Advanced Encryption Standard) ne nécessite que quelques modifications de paramètres dans le fichier sqlnet.ora pour que le redo (similaire au binlog MySQL) soit chiffré. Aucune configuration de certificat externe n'est requise et elle ne nécessite qu'un redémarrage de la base de données de secours. La modification dans sqlnet.ora et wallet est simple comme suit :

Créer un répertoire de portefeuille

mkdir /u01/app/wallet

Modifier sqlnet.ora

ENCRYPTION_WALLET_LOCATION=
 (SOURCE=
  (METHOD=file)
   (METHOD_DATA=
    (DIRECTORY=/u01/app/wallet)))

Créer un magasin de clés

ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '/u01/app/wallet' identified by root ;

Ouvrir le magasin

ADMINISTER KEY MANAGEMENT set KEYSTORE open identified by root ;

Créer une clé principale

ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY root WITH BACKUP;

En veille

copier les fichiers p12 et .sso dans le répertoire du portefeuille et mettre à jour le fichier sqlnet.ora similaire au nœud principal.

Pour plus d'informations, veuillez suivre le livre blanc TDE d'Oracle, vous pouvez apprendre du livre blanc comment chiffrer le fichier de données et rendre le portefeuille toujours ouvert.

Facilité d'utilisation et de gestion

Lorsque vous gérez ou déployez la configuration d'Oracle Data Guard, vous pouvez découvrir qu'il existe de nombreuses étapes et paramètres à rechercher. Pour répondre à cela, Oracle a créé DG Broker.

Vous pouvez certainement créer une configuration Data Guard sans implémenter le DG Broker mais cela peut vous rendre la vie beaucoup plus confortable. Lorsqu'il est implémenté, l'utilitaire de ligne de commande du courtier - DGMGRL est probablement le premier choix pour le DBA. Pour ceux qui préfèrent l'interface graphique, Cloud Control 13c a une option pour accéder à DG Broker via l'interface Web.

Les tâches que Broker peut aider sont un démarrage automatique de la récupération gérée, une commande pour le basculement/basculement, la surveillance de la réplication DG, la vérification de la configuration et bien d'autres.

DGMGRL> show configuration 
Configuration - orcl_s9s_config 

Protection Mode: MaxPerformance
  Members:

s9sp  - Primary database
    s9ss - Physical standby database 

Fast-Start Failover: DISABLED
Configuration Status:
SUCCESS   (status updated 12 seconds ago

MySQL n'offre pas de solution similaire à Oracle DG Broker. Cependant, vous pouvez étendre ses fonctionnalités en utilisant des outils comme Orchestrator, MHA et des équilibreurs de charge (ProxySQL, HAProxy ou Maxscale). La solution pour gérer les bases de données et les équilibreurs de charge est ClusterControl. L'édition Enterprise de ClusterControl vous offre un ensemble complet de fonctionnalités de gestion et de mise à l'échelle en plus des fonctions de déploiement et de surveillance proposées dans le cadre de l'édition communautaire gratuite.