La synchronisation maître-esclave MySQL signifie sauvegarde. La bibliothèque maître (Maître) synchronise les écritures de sa propre bibliothèque avec sa bibliothèque esclave (Esclave). Lorsque des situations imprévisibles se produisent dans la bibliothèque maître, l'ensemble du serveur. n'est pas disponible, puisqu'il existe également une copie des données dans la base de données esclave, les données peuvent être rapidement restaurées sans provoquer ni réduire la perte de données.
Lorsque les données de la base de données principale changent, les modifications seront synchronisées avec la base de données esclave en temps réel.
Les données sont un élément essentiel d'une application. En termes d'objectif, la synchronisation maître-esclave a un peu une signification de sauvegarde. La bibliothèque maître (Master) synchronise les écritures de sa propre bibliothèque avec sa bibliothèque esclave (Slave) en même temps Quand quelque chose. un événement imprévisible arrive à la bibliothèque maître Lorsque l'ensemble du serveur devient inutilisable en raison d'une situation, puisqu'il existe également une copie des données dans la base de données esclave, les données peuvent être rapidement restaurées sans provoquer ni réduire la perte de données.
Bien sûr, ce n'est que le premier niveau. Si le rôle de la bibliothèque maître-esclave se limite à cela, alors je pense personnellement qu'il n'est pas nécessaire de la diviser en deux bases de données. doit régulièrement envoyer le contenu de la base de données sous forme d'instantanés. Ne serait-il pas agréable d'utiliser un autre serveur ou d'envoyer le contenu écrit à un autre serveur en temps réel à chaque fois qu'il est écrit ? Cela permettra non seulement d'économiser des ressources, mais servira également l'objectif ? de reprise après sinistre et de sauvegarde.
Bien sûr, le rôle de la synchronisation maître-esclave ne peut pas se limiter à cela. Une fois que nous avons configuré la structure maître-esclave, nous ne laissons généralement pas le nœud esclave servir simplement de base de données de sauvegarde. devrait également le configurer en conséquence. Séparation en lecture et en écriture (Vous pouvez utiliser MyCat ou un autre middleware, vous pouvez en apprendre vous-même. J'en parlerai dans le prochain blog sur MyCat. La longueur peut être un peu longue, donc j'écrirai un autre article).
Dans l'environnement actuel, le nombre d'opérations de lecture dans la base de données est bien supérieur au nombre d'opérations d'écriture dans la base de données, nous pouvons donc laisser le maître fournir uniquement la fonction d'écriture, puis déplacer toutes les opérations de lecture. à la base de données esclave. C'est Nous parlons habituellement de la séparation de la lecture et de l'écriture.Cela peut non seulement réduire la pression sur le maître, mais également fournir une sauvegarde de reprise après sinistre, faisant d'une pierre deux coups.
Agrandissez horizontalement la capacité de chargement de la base de données.
Tolérance aux pannes, haute disponibilité. Basculement/Haute disponibilité
Sauvegarde des données.
Après avoir parlé du concept de synchronisation maître-esclave, parlons du principe de synchronisation maître-esclave. , le principe est aussi très simple, sans Redis Il y a tellement de concepts dans les clusters.
En fait, après avoir configuré le maître-esclave dans MySQL, tant que nous effectuons une opération d'écriture sur le nœud maître, cette opération sera enregistrée dans le journal binaire (bin-log) de MySQL . Lorsque l'esclave Lors de la connexion au maître, la machine maître ouvrira le thread de vidage binlog pour l'esclave. Lorsque le journal binaire du maître change, le thread de vidage du maître en informera l'esclave et enverra le contenu du journal binaire correspondant à l'esclave. Lorsque la synchronisation maître-esclave est activée, le nœud esclave créera deux threads, un thread d'E/S et un thread SQL. Cela peut être vu de nos propres yeux dans la construction ultérieure.
Thread I/0 : Ce thread est lié à la machine maître Lorsque le binlog de la machine maître est envoyé à l'esclave, le thread IO écrira. le contenu du journal localement dans le journal de relais.
Thread SQL : Ce fil lit le contenu du journal de relais et effectue les opérations correspondantes sur la base de données esclave en fonction du contenu du journal de relais.
Problèmes possibles : Lorsqu'il y a beaucoup de demandes d'écriture, les données esclaves et les données maîtres peuvent être incohérentes à cause du processus de transfert de journaux. est dû à un court retard du système, à un grand nombre de commandes d'écriture ou à une inadéquation de la vitesse du système.
C'est à peu près le principe de la synchronisation maître-esclave MySQL. Ce qui y joue réellement un rôle, ce sont en fait ces deux fichiers journaux, binlog et relay log.
L'environnement pour configurer la synchronisation maître-esclave cette fois : CentOS 7 , MySQL 8.0.18 (installé à l'aide du package binaire).
Cette fois, la synchronisation maître-esclave MySQL sera construite, avec un maître et deux esclaves.
Master:IP :192.168.43.201 Port:3306 Slave1:IP:192.168.43.202 Port:3306 Slave2:IP:192.168.43.203 Port:3306
Modifier le fichier de configuration
Après avoir installé MySQL, il y aura un fichier my.cnf dans le répertoire /etc/ Ouvrez le fichier et ajoutez-le. le Contenu suivant (n'oubliez pas de faire une sauvegarde avant de modifier) :
x
#该配置为Master的配置 server-id=201 #Server id 每台MySQL的必须不同 log-bin=/var/lib/mysql/mysql-bin.log #代表开启binlog日志 expire_logs_days=10 #日志过期时间 max_binlog_size=200M #日志最大容量 binlog_ignore_db=mysql #忽略mysql库,表示不同步此库
y
#该配置为Slave的配置,第二台Slave也是这么配置,不过要修改一下server-id server-id=202 expire_logs_days=10 #日志的缓存时间 max_binlog_size=200M #日志的最大大小 replicate_ignore_db=mysql #忽略同步的数据库
Ajouter un utilisateur Slave
Ouvrez le client du nœud maître, mysql -u root -p password
Créer un utilisateur create user 'Slave'@'%' identified by '123456';
Autonomiser l'utilisateur nouvellement créé : grant replication slave on '*.*' to 'Slave'@'%';
Afficher l'état du nœud maître
Une fois que les opérations ci-dessus ne posent aucun problème, nous entrons show master status dans le client pour afficher le journal binlog du maître.
配置两个Slave节点
打开两个Slave节点客户端,在我们的另外两个Slave节点中输入如下命令:
change master to master_user='Slave',master_password='123456',master_host='192.168.43.201',master_log_file='mysql-bin.000005',master_log_pos=155,get_master_public_key=1; #注意,这里的master_log_file,就是binlog的文件名,输入上图中的mysql-bin.000005,每个人的都可能不一样。 #注意,这里的master_log_pos是binlog偏移量,输入上图中的155,每个人的都可能不一样。
配置完成后,输入start slave;开启从节点,然后输入show slave status\G;查看从节点状态
可以看到,在两台Slave的状态中,我们能亲眼看到IO线程和SQL线程的运行状态,这两个线程必须都是yes,才算配置搭建完成。
通过上述步骤,就完成了MySQL主从同步的搭建,相对Redis而言MySQL配置相当简单。下面我们可以进行测试。
先看看三个MySQL的数据库状态:SHOW DATABASES;
可以看到现在数据库都是初始默认状态,没有任何额外的库。
在Master节点中创建一个数据库,库名可以自己设置。
CREATE DATABASE testcluster;
<img alt="" class="has" src="https://img.php.cn/upload/article/000/000/024/fefa55750f9a4ddaec29168c6cc022e9-4.png">
可以看到,在Slave中也出现了Master中创建的数据库,说明我们的配置没有问题,主从搭建成功。这里就不再创建表了,大家可以自己试试,创建表再往表中插入数据,也是没有任何问题的。
如果出现IO线程一直在Connecting状态,可以看看是不是三台机器无法相互连接,如果可以相互连接,那么有可能是Slave账号密码写错了,重新关闭Slave然后输入上面的配置命令再打开Slave即可。
如果出现SQL线程为NO状态,那么有可能是从数据库和主数据库的数据不一致造成的,或者事务回滚,如果是后者,先关闭Slave,然后先查看master的binlog和position,然后输入配置命令,再输入set GLOBAL SQL_SLAVE_SKIP_COUNTER=1;
,再重新start slave;
即可,如通过是前者,那么就排查一下是不是存在哪张表没有被同步,是否存在主库存在而从库不存在的表,自己同步一下再重新配置一遍即可。
在写这篇文章之前自己也被一些计算机领域的“名词”吓到过,相信有不少同学都有一样的体会,碰上某些高大上的名词总是先被吓到,例如像“分布式”、“集群”等等等等,甚至在没接触过nginx之前,连”负载均衡“、”反向代理“这样的词都让人觉得,这么高达上的词,肯定很难吧,但其实自己了解了nginx、ribbon等之后才发现,其实也就那么回事吧,没有想象中的那么难。
所以写这篇文章的初衷是想让大家对集群化或者分布式或者其他的一些技术或者解决方案不要有一种望而却步的感觉(感觉计算机领域的词都有这么一种特点,词汇高大上,但是其实思想是比较好理解的),其实自己手动配置出一个简单的集群并没有那么难。
如果学会docker之后再来配置就更加简单了,但是更希望不要只局限于会配置,配置出来的东西只能说你会配置了,但是在这层配置底下是前人做了相当多的工作,才能使我们通过简单配置就能实现一些功能,应该要深入底层,了解配置下面的工作原理,这个才是最重要的,也是体现一个程序员水平的地方。
推荐教程:mysql视频教程
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!