您好、欢迎来到现金彩票网!
当前位置:2019欢乐棋牌 > 主从复制 >

MySQL 数据库主从复制

发布时间:2019-07-29 21:58 来源:未知 编辑:admin

  MySQL 数据库的主从复制方案,与使用 scp/rsync 等命令进行的文件级别复制类似,都是数据的远程传输,只不过 MySQL 的主从复制是其自带的功能,无需借助第三方工具,而且,MySQL 的主从复制并不是数据库磁盘上的文件直接拷贝,而是通过逻辑的 binlog 日志复制到要同步的服务器本地,然后由本地的线程读取日志里面的 SQL 语句,重新应用到 MySQL 数据库中。

  MySQL 数据库支持单向、双向、链式级联、环状等不同业务场景的复制。在复制过程中,一台服务器充当主服务器(Master),接收来自用户的内容更新,而一个或多个其他的服务器充当从服务器(Slave),接收来自主服务器 binlog 文件的日志内容,解析出 SQL,重新更新到从服务器,使得主从服务器数据达到一致。

  如果设置了链式级联复制,那么从服务器本身除了充当从服务器外,也会同时充当其下面从服务器的主服务器,链式级联复制类似 ABC 的复制形式。

  下图为单向主从复制架构逻辑图,此架构只能在 Master 端进行数据写入:

  下图为双向主主复制逻辑架构图,此架构可以在 Master1 端或 Master2 端进行数据写入,或者两端同时写入数据(需要特殊设置)。

  下图为线性级联单向双主复制逻辑架构图,此架构只能在 Master1 端进行数据写入,工作场景中,Master1 和 Master2 作为主主互备,Slave1 作为从库,中间的 Master2 需要做特殊的设置。

  下图为环状级联单向多主同步逻辑架构图,任意一个点都可以写入数据,此架构比较复杂,属于极端环境下的“作品”,一般场景应慎用。

  提示:在当前的生产环境中,MySQL 主从复制都是异步的复制方式,即不是严格实时的数据同步,但是正常情况下给用户的体验是实时的。

  MySQL 主从复制集群功能使得 MySQL 数据库支持大规模高并发读写成为可能,同时有效地保护了物理服务器宕机场景的数据备份。

  PHP 和 JAVA 程序都可以通过设置多个连接文件轻松地实现对数据库的读写分离,即当语句关键字为 select 时,就去找读库的连接文件,若为 update、insert、delete 时,则连接写库的连接文件。

  通过程序实现读写分离的缺点就是需要开发人员对程序进行改造,使其对下层不透明,但这种方式更容易开发和实现,适合互联网业务场景。

  MYSQL-proxy、Amoeba 等代理软件也可以实现读写分离,但是这些软件的稳定性和功能一般,不建议生产场景使用。绝大多数公司常用的还是在应用端开发程序实现读写分离。

  MySQL 的主从复制是一个异步的复制过程(虽然一般情况下感觉是实时的),数据将从一个 MySQL 数据库(Master)复制到另一个 MySQL 数据库(Slave),在 Master 和 Slave 之间实现整个主从复制的过程是由三个线程参与完成的,其中有两个线程(SQL 和 I/O )在 Slave 端,另一个线程(I/O)在 Master 端。

  ① 在 Slave 服务器上执行 start slave 命令开启主从复制开关,开始进行主从复制。

  ② 此时 Slave 服务器的 I/O 线程会通过在 Master 上已经授权的复制用户权限请求连接 Master 服务器,并请求 Master 从指定 binlog 日志文件的指定位置(日志文件名和位置就是在配置主从服务时执行 change master 命令指定的)发送 binlog 日志内容。

  ③ Master 服务器接收到来自 Slave 服务器的 I/O 线程的请求后,其上负责复制的 I/O 线程会根据 Slave 服务器的 I/O 线程请求的信息分批读取指定 binlog 日志文件指定位置之后的 binlog 日志信息,然后返回给 Slave 端的 I/O 线程,返回的信息中除了 binlog 日志内容外,还有在 Master 服务器端记录的新的 binlog 文件名称,以及在新的 binlog 中的下一个指定更新位置。

  ④ 当 Slave 服务器的 I/O 线程获取到 Master 服务器上 I/O 线程发送的日志内容、日志文件及位置点后,会将 binlog 日志内容依次写到 Slave 端自身的 Relay Log(中继日志)文件的最末端,并将新的 binlog 文件名和位置记录到 master-info文件中,以便下一次读取 Master 端新 binlog 日志时能够告诉 Master 服务器从新 binlog 日志的指定文件及位置开始请求新的 binlog 日志内容。

  ⑤ Slave 服务器端的 SQL 线程会实时检测本地 Relay Log 中 I/O 线程新增加的日志内容,然后及时地把 Relay Log 文件中的内容解析成 SQL 语句,并在自身 Slave 服务器上按解析 SQL 语句的位置顺序执行应用这些 SQL 语句,并在中记录当前应用中继日志的文件名及位置点。

  ⑥ 经过了上面的过程,就可以确保在 Master 端和 Slave 端执行了同样的 SQL 语句。当复制状态正常时,Master 端和 Slave 端的数据是完全一样的。当然,MySQL 的复制机制也有一些特殊情况,详情查看官方手册。

  ② 复制时,主库有一个 I/O 线程,从库有两个线程,及 I/O 和 SQL 线程;

  ⑤ binlog 文件只记录对数据内容有更改的 SQL 语句,不记录任何查询语句。

  主从复制的搭建可以用两台 MySQL 服务器或者一台 MySQL 多实例服务器完成,这里以一台有两个实例的 MySQL 数据库服务器来完成。

  一般做主从复制,主从服务器在不同的机器上,并且监听的端口均为默认的 3306。

  提示:上面是官方文档给的备份方式,生产场景中的备份常用 -x 参数锁表,用 --master-data 参数记录 binlog 的文件及位置。

  ② 配置 my.cnf 文件:主库配置 log-bin 和 server-id 参数;从库配置 server-id,该值不能和主库及其他从库一样,一般不开启从库 log-bin 功能。注意配置后需要重启服务使之生效。

  ③ 登录主库,增加从库连接主库同步的账户,例如:rep,并授权 replication slave 同步的权限。

  ⑤ 新开窗口,Linux 命令行备份或导出原有的数据库数据,并拷贝到从库所在的服务器目录。如果数据量很大,并且允许停机,可停机打包,而不用 mysqldump 。

  ⑩ 从库 show slave status\G,检查同步状态,并在主库进行更新测试。

  提示:配置文件里的参数和 show variables 里的参数不一样。

  提示:在 MySQL 5.1 中,锁表的语句是: flush tableswith read lock;这个锁表语句的时间,在不同引擎的情况,会受下面参数的控制。锁表时如果超过设置时间不操作,会自动解锁。

  由于切换 binlog 导致 show master 位置变化无影响。(数据没有更新)

  ③ 主库通过记录 binlog 实现对从库的同步。binlog 记录数据库的更新语句。

  ④ 主库一个 I/O 线程,从库由一个 I/O 线程和一个 SQL 线程来完成;

  ③ 登陆主库增加由于从库连接主库同步的账户如 rep 并授权 replication slave 的权限;

  以下是主服务器的线程最常见状态。如果在主副武器上没有看到任何 binlog dump 线程说明复制没有运行,即没有连接任何从服务器。

  表示线程已经读完二进制日志文件并且正打开下一个要发送到从服务器的日志文件。

  表示线程已经把所有更新的 binlog 内容发给从库,目前正在等待 binlog 的更新。

  建立主从服务器之间的连接后立即临时出现的状态。线程向主服务器发送一条请求,索取从请求的二进制日志文件名和位置开始的二进制日志的内容。

  如果二进制日志转储请求失败(由于没有连接),线程进入睡眠状态,然后定期尝试重新连接,可以使用 --master-connect-retry 选项指定重试之间的间隔。

  线程已经连接上主服务器,正等待二进制日志事件到达。如果主服务器正空闲,会持续较长的时间,如果等待持续 slave_read_timeout 秒,则发生超时。此时,线程认为连接被中断并企图重新连接。

  线程已经读取一个事件,正将它复制到中继日志供 SQL 线 复制从 SQL 线程状态

  线程已经处理了中继日志文件中的所有事件,现在正等待 I/O 线程将新事件写入中继日志。

  通过 MySQL 线程同步状态查看数据库同步是否完成,用于主库宕机或者人工数据库主从切换迁移等。主库宕机选择最快的从库提升为主,就需要查看线程状态,当然也可以利用 MySQL 的半同步功能,选择固定的库提升为主。

  # 上面两个参数的 yes 表示同步的状态是 OK 的,但是是否有延迟等无法体现出来。

  1016:文件无法打开,使用后台修复或者使用 phpmyadmin 进行修复。

  --binlog-do-db 二进制日志记录的数据库(多个库用逗号分隔)。

  --binlog-ignore-db 二进制日志忽略的数据库(多个库用逗号分隔)。

  提示:由于从库设置了 read-only,非 SUPER 权限是无法写入的,root 用户有 SUPER 权限,所以依旧可以在配置 read-only 的从库写入数据。创建非 SUPER 权限的用户测试:

  MySQL 错误代号1007: MYSQL数据库已存在,创建数据库失败。

  ① 对于普通的互联网业务,忽略问题不是很大,当然要确认不影响公司业务的前提下。

  ② 企业场景解决主从同步,比主从不一致更重要。如果主从数据一致也很重要,再找时间恢复从库。

  ③ 主从数据不一致和保持主从同步持续状态哪个更总要需要根据不同业务选择。

  此时主库创建从库已经存在的数据库,就不会产生不同步的问题(忽略 1007 错误)。

  ① 当前主库还要作为其他从库的主库,也就是级联同步,需要开启 binlog;

  ① 确保更新完毕,看看从库哪个最快,经过测试没有延迟的情况 POS 差距很小,甚至是一致的。通过查看 master.info 的内容来确定将哪个(数据最新,跟主库一致性更高的)从库提升为主库。

  ③ 提示:如果主库只是服务宕机,服务器正常,可以将主库服务器的 binlog 拉倒要提升为主库的从库,用来补全数据。

  提示:如果提升为主库的从库存在忽略授权表,read-only 等设置,需要清理这些设置。

  ⑤ 如果主库服务器没有宕机,需要去主库拉取 binlog 补全提升主库的从库数据。

  ⑦ 修改程序配置文件从主库指向从库、平时访问数据库用域名则可直接改 hosts 解析。

  半同步下的一主多从恢复,直接对设置半同步的从库确定为主库。让某一个稳定的从库和主库完全一致,即主库和这个从库都更新数据完毕后再返回给用户更新数据成功的消息。

  主从之间网络延迟,或者从库有问题的时候会降低用户体验。(可设置超时时间为10秒)。

http://api-crypt.com/zhucongfuzhi/158.html
锟斤拷锟斤拷锟斤拷QQ微锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷锟斤拷微锟斤拷
关于我们|联系我们|版权声明|网站地图|
Copyright © 2002-2019 现金彩票 版权所有