Cet article résume les différences entre OceanBase et MySQL dans les commandes de synchronisation maître-veille et la protection des données.
Auteur : He Wenchao
Membre de l'équipe DBA du service de livraison dans la région sud d'Acson, principalement responsable du dépannage MySQL, de la transformation de l'architecture MySQL haute disponibilité et du support technique lié à OceanBase. Comme le football, le badminton.
Source de cet article : contribution originale
Produit par la communauté open source Aikesheng, le contenu original ne peut être utilisé sans autorisation, veuillez contacter l'éditeur et indiquer la source pour la réimpression.
arrière-plan
Dans la synchronisation MySQL master-standby, il existe stop slave；reset slave allde telles commandes pour contrôler l'arrêt du thread master-standby et supprimer les informations liées au master-standby.
Existe-t-il donc un scénario similaire dans l'OceanBase distribué ? Les commandes sont-elles les mêmes pour les deux ? Quelle est la différence?
illustrer
- Dans MySQL, les bases de données principale et de secours sont synchronisées ; dans OceanBase, des scénarios similaires existent dans les clusters principal et de secours.
- Les clusters actifs et de secours OceanBase n'ont pas
stop slave; reset slave allla commande, mais il existe des scénarios similaires.
Introduisons le " " dans OceanBase en détail stop slave; reset slave all.
Préparation environnementale
Un ensemble de clusters actifs et de secours OceanBase.
arrêter l'esclave dans OceanBase
Les expériences suivantes sont utilisées pour vérifier comment le colmatage affecte l'état des clusters actifs et en veille d'OceanBase.
Expérience 1 : Éteignez le sabot, le cluster est-il disponible ?
Désactivez la synchronisation des obstructions ( sysfonctionne sur le locataire du cluster principal).
MySQL [(none)]> alter system disable cluster synchronization 'hwc_cluster' cluster_id=1682755173;
//hwc_clog：备集群名
//cluster_id：备集群 ID
Afficher l'état de la synchronisation ( sysfonctionnant sur le locataire du cluster principal).
MySQL [(none)]> select * from oceanbase.v$ob_standby_status\G;
*************************** 1. row ***************************
cluster_id: 1682755173
cluster_name: hwc_cluster
cluster_role: PHYSICAL STANDBY
cluster_status: DISABLED
current_scn: 1688630508000921
rootservice_list: 10.186.64.63:2882:2881
redo_transport_options: ASYNC NET_TIMEOUT = 30000000
protection_level: MAXIMUM PERFORMANCE
synchronization_status: CLUSTER IS DISABLED
1 row in set (0.00 sec)
//synchronization_status：CLUSTER IS DISABLED
//主备集群断开 clog 日志同步
Conclusion : désactivez la synchronisation des obstructions et les clusters actifs et de secours OceanBase sont désactivés.
Expérience 2 : Dans des cas particuliers, de nouvelles données sont-elles perdues ?
Vérifiez que lorsque [Temps de déconnexion de la synchronisation du colmatage des clusters actif et en veille] > [Temps de rétention du colmatage], si la synchronisation du colmatage entre les clusters actif et en veille est à nouveau activée, les nouvelles données sont-elles perdues ?
Modifiez les jours de rétention de sabot à 1 jour :
MySQL [(none)]> ALTER SYSTEM SET clog_expire_days=1;
Après 1 jour, le cluster principal insère de nouvelles données.
MySQL [lpp]> select * from test;
+------+------+
| c1 | c2 |
+------+------+
| 1 | eee |
| 2 | eee |
| 3 | eee |
+------+------+
3 rows in set (0.01 sec)
MySQL [lpp]> insert into test(c1,c2) values(4,'ddd');
Query OK, 1 row affected (0.02 sec)
Activer la synchronisation de blocage ( sysopérée sur le locataire principal du cluster).
MySQL [(none)]> alter system enable cluster synchronization 'hwc_cluster' cluster_id=1682755173;
//hwc_clog：备集群名
//cluster_id：备集群 ID
Vérifiez si le cluster de secours s'est synchronisé avec les nouvelles données ? (la chaîne de connexion doit être ajoutée -c)
MySQL [lpp]> select /*+READ_CONSISTENCY(WEAK) */ * from test;
+------+------+
| c1 | c2 |
+------+------+
| 1 | eee |
| 2 | eee |
| 3 | eee |
| 4 | ddd |
+------+------+
4 rows in set (0.00 sec)
Conclusion : Le cluster de secours se synchronise avec les nouvelles données.
Principe : Lorsque la synchronisation de blocage des clusters actifs et en veille est activée, la cohérence des données est automatiquement détectée. Si les données s'avèrent incohérentes, les données de référence sont automatiquement extraites pour la synchronisation.
4 : Une fois la synchronisation du clog arrêtée, le cluster de secours est-il disponible ?
Lorsque le clog est normalement synchronisé, le cluster de secours interroge les données (-c doit être ajouté à la chaîne de connexion).
MySQL [LPP]> select /*+READ_CONSISTENCY(WEAK) */ * from test;
+------+------+
| c1 | c2 |
+------+------+
| 1 | eee |
| 2 | eee |
| 3 | eee |
| 4 | ddd |
+------+------+
4 rows in set (0.00 sec)
Arrêtez la synchronisation du blocage ; les données de requête du cluster de secours (la chaîne de connexion doit ajouter -c).
MySQL [lpp]> select /*+READ_CONSISTENCY(WEAK) */ * from test;
ERROR 4012 (HY000): Timeout
Conclusion : Lorsque la synchronisation des clogs est arrêtée, le cluster de secours est indisponible.
réinitialiser l'esclave tout dans OceanBase
Dans MySQL, en reset slave allsupprimant les informations relatives au maître et à la sauvegarde, la bibliothèque esclave peut être utilisée comme une bibliothèque indépendante, accessible en lecture et en écriture.
Dans OceanBase, le découplage des clusters actifs et en veille permet de supprimer la relation entre les clusters actifs et en veille. Vous pouvez vous référer aux documents officiels . Spécifiquement liés à l'environnement de production, les étapes de découplage sont plus lourdes et ne seront pas élaborées ici.
La différence entre OceanBase et MySQL ?
Alors, quelle est la différence entre les clusters actifs et en attente d'OceanBase et les bases de données actives et en attente de MySQL dans la fermeture des threads actifs et en attente et la suppression des informations pertinentes de l'actif et de l'attente ?
MySQL
- Emplacement de l'opération de commande : base de données de secours
- Commande d'arrêt de la synchronisation :
stop slave - Supprimez la relation maître-veille :
reset slave all - Lorsque la synchronisation binlog est déconnectée et que le journal du nœud principal expire, redémarrez la synchronisation du journal : la base de données de secours perdra des données
- Lorsque la synchronisation binlog est déconnectée, si la base de données de secours est disponible : la base de données de secours est disponible
OceanBase
- Emplacement de l'opération de commande : cluster principal
- Commande d'arrêt de la synchronisation :
alter system disable cluster synchronization 'hwc_cluster' cluster_id=xxxxxxxxx - Supprimer la relation maître-secours : Découplage de la bibliothèque maître-secours (plus encombrant, OCP V3.3.0 peut fonctionner avec un écran blanc)
- Lorsque la synchronisation du clog est déconnectée et que le journal du nœud principal expire, redémarrez la synchronisation du journal : le cluster de secours ne perdra pas de données
- Lorsque la synchronisation clog est déconnectée, la base de données de secours est-elle disponible : le cluster de secours est indisponible
Pour plus d'articles techniques, veuillez visiter : https://opensource.actionsky.com/
À propos de SQLE
Le SQLE de la communauté open source Akson est un outil d'audit SQL pour les utilisateurs et les gestionnaires de bases de données, qui prend en charge l'audit multi-scénarios, prend en charge les processus en ligne standardisés, prend en charge de manière native l'audit MySQL et dispose de types de bases de données évolutives.
SQLE obtenir
| taper | adresse |
|---|---|
| Dépôt | https://github.com/actiontech/sqle |
| document | https://actiontech.github.io/sqle-docs/ |
| publier des nouvelles | https://github.com/actiontech/sqle/releases |
| Documentation sur le développement du plug-in d'audit des données | https://actiontech.github.io/sqle-docs/docs/dev-manual/plugins/howtouse |