当前位置：首页 > news >正文

有没有专门做售楼部包装的网站seo技术交流

news 2026/4/8 19:58:41

有没有专门做售楼部包装的网站,seo技术交流,花生日记网站建设,wordpress添加自定义链接主从复制主从复制的含义主从复制：在一个mysql的集群当中，至少3台，即主1台，从2台。当有数据写入时，主负责写入本库，然后把数据同步到从服务器。一定是在主服务器写入数据，从服务器的写入…

主从复制

主从复制的含义

主从复制：在一个mysql的集群当中，至少3台，即主1台，从2台。

当有数据写入时，主负责写入本库，然后把数据同步到从服务器。

一定是在主服务器写入数据，从服务器的写入数据不会同步到集群。

主从复制的模式

1、异步复制：mysql的默认复制方式，主在执行完客户端提交的数据之后，结果会立即返回给客

户端，主库不关心数据是否被从库接受和处理的。主库如果崩溃，主库的未提交数据可能不能同步

到从库，可能导致数据的不完整，可以使用MHA进行故障切换。

2、全同步复制：主库执行完客户端提交的数据，从库也处理完了该数据，才会提交给客户端。需

要等到所有的库都完成写入，才能进行下一步操作。

3、半同步复制：介乎于全同步模式和异步模式之间，主库接受到写入操作，会等待至少一个从库

完成了写入之后才能返回给客户端。

主从复制当中的延迟问题

1、网络延迟：数据库尽量部署在同一地域的同一数据中心之间的相同的内网局域网。

2、硬件原因：磁盘的I/O性能，CPU的核心数，加大内存。尽量使用物理主机来部署数据库。

3、架构方面：我在配置好主从模式之后，尽量的保证所有的写入都是从主库完成。

4、mysql的配置：mysql的双一设置（配置/etc/my.cnf）

1、innodb_flush_log_at_trx_commit=1

1：每次提交事务时，都会刷新事务的日志，确保事务的持久性，提高了数据的安全性，但会降低了性能。
0：事务提交时，不刷新日志，而是每秒进行一次刷新，性能提高了，安全相对低。
2：事务提交时，事物的日志写入操作系统的内存，不进行物理刷新（不保存到硬盘）。

2、sync_binlog=1

1：每次提交事务时，二进制日志都会刷新到磁盘，确保日志的持久性。
0：每次提交事务时，二进制日志写入操作系统的内存，不进行物理刷新。
N：每提交N次事务，就进行刷新。

补充：

1、log-slave-updates=0

不将从库的更新写入二进制日志，避免在主从复制陷入死循环。

2、innodb_buffer_pool_size

存储引擎的缓冲池的大小，增大空间可以提高整个数据库的性能。这个空间时占用内存的，大小的设置是内存的一半、或者3分之一。

主从复制实验

我们建立一个主从复制架构，如下：

主：mysql1，192.168.254.31

从1：mysql2，192.168.254.32

从2：mysql3，192.168.254.33

nginx1：amoba jdk1.6

nginx2：客户端

1、配置主服务器的配置文件vim /etc/my.cnf，添加如下内容，并重启mysql服务

log-bin=master-bin #开启二进制日志
log-slave-updates=true #让从库可以从主库当中获取二进制日志的更新，写入到自己的日志当中

2、配置两台从服务器的配置文件vim /etc/my.cnf，添加如下内容，并重启mysql服务

主从服务器之间的server-id不能重复
relay-log=relay-log-bin #指定了从服务器上中继日志的文件
relay-log-index=slave-relay-bin.index #中继日志索引文件的名称
relay_log_recovery = 1 #指定了从服务器在启动时，是否执行中继日志的恢复操作，保持数据的一致。

3、在主服务器上创建用户，用于主从之间通信

CREATE USER 'myslave'@'192.168.254.%' IDENTIFIED WITH mysql_native_password BY '123456'; #创建用户
GRANT REPLICATION SLAVE ON *.* TO 'myslave'@'192.168.254.%' ; #赋权
FLUSH PRIVILEGES; #刷新权限

4、获取主服务器二进制文件名和位置

5、开启从服务器同步，建立与主服务器的同步关系

CHANGE master to master_host='192.168.254.31',master_user='myslave',master_passwoword='123456',master_log_file='master-bin.000001',master_log_pos=857;