MySQL actuellement en application n'adopte pas de stratégie de sauvegarde à chaud sur deux machines. Cependant, compte tenu de la haute disponibilité du système, une sauvegarde à chaud sur deux machines est nécessaire. sauvegarde à chaud des données, il peut réaliser davantage la séparation de la lecture et de l'écriture et améliorer les performances d'accès aux données dans les applications. Pourquoi ne pas le faire Actuellement, j'ai quelques machines inactives, alors j'ai commencé à le faire.
Machine A : (10.0.9.199), Machine B : (10.0.9.1)
Parce qu'il s'agit d'abord d'une sauvegarde à chaud bidirectionnelle. configurez la base de données One (db1) comme maître et la base de données de sauvegarde (db2) sur B comme esclave. C'est une direction ; puis configurez db2 comme maître et db1 comme esclave
log-bin=mysql-0-bin #设定生成log文件名 #机器A配置 server-id=9199 # 主ID，与从ID不能相同 binlog-do-db=webgps4_0 #设置同步数据库名 binlog-ignore-db=mysql #避免同步mysql用户配置 replicate-do-db=webgps4_0 // 两处webgps4_0是一致的 replicate-ignore-db=mysql
log-bin=mysql-1-bin #设定生成log文件名 #以下为机器B配置 server-id=9001 # 主ID，与从ID不能相同 binlog-do-db=webgps4_0 #设置同步数据库名 binlog-ignore-db=mysql #避免同步mysql用户配置 replicate-do-db=webgps4_0 // 两处webgps4_0是一致的 replicate-ignore-db=mysql
CREATE USER 'test'@'10.0.9.1' IDENTIFIED BY '123456'; //test为账号，10.0.9.1表示账号只能从指定id也就是B机器访问，最后123456是密码，机器A上执行 CREATE USER 'test'@'10.0.9.199' IDENTIFIED BY '123456'; //机器B上执行
grant replication slave,reload,create user, super on *.* to 'test'@'10.0.9.1' IDENTIFIED BY '123456'; // 机器A上执行 grant replication slave,reload,create user, super on *.* to 'test'@'10.0.9.199' IDENTIFIED BY '123456'; // 机器B上执行
mysql> change master to
-> master_host = '10.0.9.1',
-> master_port = 3306,
-> master_user = 'test',
-> master_password = '123456'; //机器A上执行，A为slave
mysql> change master to
-> master_host = '10.0.9.199',
-> master_port = 3306,
-> master_user = 'test',
-> master_password = '123456'; //机器B上执行，B为slave
Puisqu'il s'agit d'une sauvegarde bidirectionnelle, de nombreuses opérations dans la configuration sont répétées, mais l'ordre maître-esclave est incohérent, l'une est en avant et l'autre en arrière. La sauvegarde bidirectionnelle a été implémentée ici. Vous pouvez désormais effectuer certaines opérations dans les deux bibliothèques pour voir l'effet.
Actuellement, seuls db1 et son maître-esclave bidirectionnel de sauvegarde sont configurés, ce qui signifie qu'un seul schéma est garanti comme étant en veille chaude. Dans les applications réelles, plusieurs schémas sont souvent utilisés pour réduire la pression sur un seul serveur, comme par exemple. le schéma de la machine A dans cet article La sauvegarde est sur B, et la sauvegarde de B est sur C. Certaines sauvegardes sont configurées en anneau. Il convient de noter que lors de la configuration du Hot Standby sur la machine B, la configuration du maître ou de l'esclave ne peut pas être effectuée dans l'instance de base de données précédente. Une configuration répétée sur le même numéro de port écrasera la précédente. Par conséquent, vous devez utiliser mysqld_multi pour démarrer plusieurs instances. sur une seule instance mysql, la configuration est effectuée dans une autre instance mysql. Pour la configuration de mysqld_multi, consultez le billet de blog : MySQL - Démarrage de plusieurs instances MySQL sur une seule machine sous Linux (mysqld_multi
)
La bibliothèque principale doit activer le journal Bin, et la bibliothèque principale et la bibliothèque esclave doivent avoir des ID de serveur uniques.
La bibliothèque esclave doit clairement savoir à quelle position de décalage de quel fichier journal Bin dans la bibliothèque principale commencer la copie
La bibliothèque esclave. ne peut copier qu'à partir de la bibliothèque principale La base de données désignée, ou certaines tables de données de la base de données
Les noms de base de données de la base de données maître et de la base de données esclave peuvent être différents, mais cela est toujours recommandé utiliser le même nom
Les versions MySQL de la base de données maître et de la base de données esclave doivent être cohérentes
À partir de MySQL3.23.15, MySQL prend en charge la réplication asynchrone unidirectionnelle. En d'autres termes, un serveur MySQL agit comme maître (base de données principale), un ou plusieurs serveurs MySQL agissent comme esclaves (bases de données esclaves) et les données sont répliquées de manière asynchrone du maître vers les esclaves. Notez que cette réplication est asynchrone et différente de l'implémentation de la réplication synchrone de MySQL (cette implémentation est appelée MySQL Cluster).
Lorsque la bibliothèque principale est mise à jour, la bibliothèque principale écrira le SQL de l'opération de mise à jour dans le journal binaire (Bin log) et maintiendra un index du fichier journal binaire pour faciliter la rotation du fichier journal (Rotation). Lorsque la bibliothèque esclave démarre la réplication asynchrone, la bibliothèque esclave démarre deux threads d'E/S, dont l'un se connecte à la bibliothèque principale, obligeant la bibliothèque principale à transférer les modifications du journal binaire à la bibliothèque esclave et à écrire le journal renvoyé. localement. Un autre thread est chargé de lire le journal binaire écrit localement et de l'exécuter localement pour refléter ce changement. L'ancienne version n'activait qu'un seul thread d'E/S lors de la copie pour implémenter ces deux parties de la fonction.
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!
mysql modifier le nom de la table de données
MySQL crée une procédure stockée
La différence entre MongoDB et MySQL
Comment vérifier si le mot de passe MySQL est oublié
mysql créer une base de données
niveau d'isolement des transactions par défaut de MySQL
La différence entre sqlserver et mysql
mysqlmot de passe oublié
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
