MySQL5.7基于GTID模式下的单项主从复制
2017年3月
目录
MySQL5.7基于GTID模式下的单项主从复制 (1)
1 文档介绍 (3)
1.1 文档目的 (3)
1.2 文档范围 (3)
1.3 读者对象 (3)
1.4 参考文献 (3)
1.5 术语与缩写解释 (3)
2 安装MySQL (3)
2.1 操作系统磁盘分区 (3)
2.2 基础环境准备 (4)
2.2.1 禁止iptables (4)
2.2.2 禁止 selinux (4)
2.3 主从分别安装MySQL (4)
2.3.1 上传MySQL安装包 (4)
2.3.2 添加组和用户 (5)
2.3.3 解压MySQL安装包 (5)
2.3.4 创建软链接 (5)
2.3.5 创建基本目录 (5)
2.3.6 创建/etc/https://www.doczj.com/doc/da3912647.html,f配置文件 (5)
2.3.7 数据库初始化 (6)
3 基于GTID配置主从同步 (8)
3.1 主从开启GTID模式 (8)
3.2 创建主从复制用户 (8)
3.3 备份主库数据 (8)
3.4 恢复从库数据 (9)
3.5 从库开启同步 (9)
3.6 验证主从数据是否一致 (9)
1文档介绍
1.1文档目的
本文档主要描述MySQL5.7在GTID模式下如何实现主从复制，这里以操作系统centos 6.4，数据库版本5.7.17为例。
1.2文档范围
1.3读者对象
项目实施人员、安装与维护人员等。
1.4参考文献
1.5术语与缩写解释
2安装MySQL
2.1操作系统磁盘分区
说明：swap不要划分,对于频繁进行读写操作的OLTP系统而言，响应时间过长很可能会直接拖垮整个系统。
对于数据库压力比较大的服务器，可以在考虑将数据文件与日志文件分开存储。也就是在安装操作系统时，单独划分/logs磁盘空间。
2.2基础环境准备
2.2.1禁止iptables
[root@MySQL-Node1 ~]# /etc/init.d/iptables stop
[root@MySQL-Node1 ~]# chkconfig --list|grep iptables
[root@MySQL-Node1 ~]# chkconfig iptables off
2.2.2禁止 selinux
[root@MySQL-Node1 ~]# getenforce 0
[root@MySQL-Node1 ~]# vim /etc/sysconfig/selinux
把SELINUX=enforcing 替换为：
SELINUX=disabled
2.3主从分别安装MySQL
2.3.1上传MySQL安装包
将MySQL安装包mysql-5.7.17-linux-glibc2.5-x86_64.tar.gz上传至/opt/software目录下。[root@MySQL-Node1 ~]# cd /opt/software/
[root@MySQL-Node1 software]# ls
mysql-5.7.17-linux-glibc2.5-x86_64.tar.gz
2.3.2添加组和用户
[root@MySQL-Node1 ~]# groupadd mysql
[root@MySQL-Node1 ~]# useradd -g mysql -s /sbin/nologin -d /opt/mysql mysql
[root@MySQL-Node1 ~]# id mysql
uid=500(mysql) gid=500(mysql) 组=500(mysql)
说明：/opt/mysql为MySQL软件安装目录
2.3.3解压MySQL安装包
将MySQL安装包解压至/opt/mysql目录
[root@MySQL-Node1 ~]#mkdir /opt/mysql
[root@MySQL-Node1 ~]# cd /opt/mysql/
[root@MySQL-Node1 mysql]# tar -zxvf /opt/software/mysql-5.7.17-linux-glibc2.5-x86_64.tar.gz [root@MySQL-Node1 mysql]# ls -lh
total 4.0K
drwxr-xr-x 9 7161 31415 4.0K Jul 12 21:03 mysql-5.7.17-linux-glibc2.5-x86_64
[root@MySQL-Node1 mysql]# du -sh mysql-5.7.17-linux-glibc2.5-x86_64/
2.5G mysql-5.7.17-linux-glibc2.5-x86_64/ //MySQL安装目录大小为2.5G
2.3.4创建软链接
[root@MySQL-Node1 mysql]# cd /usr/local/
[root@MySQL-Node1 local]# ln -s /opt/mysql/mysql-5.7.17-linux-glibc2.5-x86_64 mysql
2.3.5创建基本目录
[root@MySQL-Node1 ~]# mkdir -p /data/mysql/mysql3306
[root@MySQL-Node1 ~]# cd /data/mysql/mysql3306
[root@MySQL-Node1 mysql3306]# mkdir data
[root@MySQL-Node1 mysql3306]# mkdir logs
[root@MySQL-Node1 mysql3306]# mkdir tmp
[root@MySQL-Node1 mysql3306]# chown -R mysql:mysql /data/mysql/mysql3306
2.3.6创建/etc/https://www.doczj.com/doc/da3912647.html,f配置文件
直接在/etc目录下替换或者新建https://www.doczj.com/doc/da3912647.html,f文件。内容见附件
https://www.doczj.com/doc/da3912647.html,f
注意：server-id = 283306 以ip最后一位+端口的形式展示。修改格式如ip为
192.168.1.28，端口为3306。请根据实际情况调整。
2.3.6.1添加环境变量
[root@MySQL-Node1 mysql]# echo $PATH
echo "export PATH=$PATH:/usr/local/mysql/bin">> /etc/profile
source /etc/profile
2.3.7数据库初始化
初始化命令：
[root@MySQL-Node1 ~]# /usr/local/mysql/bin/mysqld --initialize
注意：5.7版本初始化后会得到密码（在error.log日志中找到）：PYtcUiQvx6)/ 必须记住此密码，用此登录后做权限更改操作。
[root@MySQL-Node1 logs]# cat error.log |grep password
2016-12-27T01:00:31.224648Z 1 [Note] A temporary password is generated for root@localhost: PYtcUiQvx6)/
2.3.7.1创建启动脚本
[root@MySQL-Node1 data]# cd /usr/local/mysql/
[root@MySQL-Node1 mysql]# cp support-files/mysql.server /etc/init.d/mysql
2.3.7.2启动MySQL服务
[root@MySQL-Node1 mysql]# /etc/init.d/mysql start
Starting MySQL... [ OK ]
或者也可以这种方式启动：
/usr/local/mysql/bin/mysqld --defaults-file=/etc/https://www.doczj.com/doc/da3912647.html,f &
2.3.7.3登录MySQL并更改密码
[root@MySQL-Node1 ~]# mysql -S /data/mysql/mysql3306/tmp/mysql.sock -p
Logging to file '/data/mysql/mysql3306/logs/query.log'
Enter password: ---输入前面的密码PYtcUiQvx6
注意：成功登录后执行命令提示如下。
(unknown)@localhost:mysql.sock 09:18:40 [(none)]>show databases; ERROR 1820 (HY000): You must reset your password using ALTER USER statement before executing this statement. 登录无操作权限，前面的提示符是“(unknown)”
2.3.7.4更改MySQL数据库root用户密码
(unknown)@localhost:mysql.sock 09:22:48 [(none)]>alter user user() identified by 'user'; Query OK, 0 rows affected (0.00 sec)
root@localhost:mysql.sock 09:24:51 [(none)]>---修改密码后，前面的提示符由“ unknown”修改为“root”
root@localhost:mysql.sock 09:24:51 [(none)]>show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| sys |
+--------------------+
4 rows in set (0.00 sec)
root@localhost:mysql.sock 09:50:39 [(none)]>select user,host,authentication_string,plugin from https://www.doczj.com/doc/da3912647.html,er;
注意：https://www.doczj.com/doc/da3912647.html,er中无“password”字段;plugin 为“ mysql_native_password”表示采用本地的加密认证，也可以采用其它加密方式，如集中认证等
+-----------+-----------+-------------------------------------------+-----------------------+
| user | host | authentication_string | plugin | +-----------+-----------+-------------------------------------------+-----------------------+
| root | localhost | *52387EA2A80926B64E3F988ED7B1585AB22F5C14 | mysql_native_password | | mysql.sys | localhost | *THISISNOTAVALIDPASSWORDTHATCANBEUSEDHERE | mysql_native_password | +-----------+-----------+-------------------------------------------+-----------------------+
2 rows in set (0.00 sec)
2.3.7.5设置root远程连接
"root@localhost Mon Aug 17 16:32:39 2015 16:32:39 [(none)]> grant all privileges on *.* to root@"%" identified by 'user' with grant option;
"root@localhost Mon Aug 17 16:32:47 2015 16:32:47 [(none)]>flush privileges;
"root@localhost Mon Aug 17 16:33:02 2015 16:33:02 [(none)]>exit
3基于GTID配置主从同步
3.1主从开启GTID模式
"root@localhost Mon Nov 23 19:28:06 2015 19:28:06 [(none)]>show variables like '%GTID%';
+---------------------------------+------------------------------------------+
| Variable_name | Value |
+---------------------------------+------------------------------------------+
| binlog_gtid_simple_recovery | OFF |
| enforce_gtid_consistency | ON |
| gtid_executed | |
| gtid_mode | ON |
| gtid_next | AUTOMATIC |
| gtid_owned | |
| gtid_purged | a0475f56-8dd2-11e5-aa53-08002722e892:1-5 |
| simplified_binlog_gtid_recovery | OFF |
+---------------------------------+------------------------------------------+
enforce_gtid_consistency、gtid_mode 显示为“ON”表示已经开启GTID模式；如果显示为“OFF”，则修改配置文件https://www.doczj.com/doc/da3912647.html,f将参数修改如下后，再重启MySQL服务器。
#GTID
gtid_mode = on
enforce_gtid_consistency = on
[root@node1 ~]#service mysqld restart
3.2创建主从复制用户
"root@localhost Mon Nov 23 19:28:06 2015 19:28:06 [(none)]>grant replication slave on *.* to 'repl'@'%' identified by 'repl';
3.3备份主库数据
在主备库上分别创建备份文件目录：/data/backup
注意：密码为user
[root@node1 backup]#/usr/local/mysql/bin/mysqldump -u root -p -S /data/mysql/mysql3306/tmp/mysql.sock --master-data=2 --single-transaction -A >db.sql
3.4恢复从库数据
将备份数据从28主服务器传到29从服务器上：
[root@node1 backup]# scp db.sql root@192.168.1.29:/data/backup/
注意：若从库不是新库，而是有数据的旧库，则执行（若从库为新库，则忽略此步，一般都需要做此操作）：
mysql> reset master;
29服务器开始恢复主库数据：
[root@node2 backup]# time mysql -S /data/mysql/mysql3306/tmp/mysql.sock < db.sql
Logging to file '/data/mysql/mysql3306/logs/query.log'
real 0m1.685s
user 0m0.060s
sys 0m0.014s
3.5从库开启同步
"root@localhost WedNov1817:59:34201517:59:34[(none)]>change master to master_host='192.168.1.28',master_port=3306,master_user='repl',master_password='repl',master _auto_position=1;
Query OK,0 rows affected,2 warnings (0.01 sec)
"root@localhost WedNov1817:59:41201517:59:41[(none)]>start slave;
Query OK,0 rows affected (0.01 sec)
3.6验证主从数据是否一致
在从库上运行命令：show slave status\G
满足以下几点：Slave_IO_Running、Slave_SQL_Running都显示为“YES”
Retrieved_Gtid_Set(从库接收到主库GTID事务) == Executed_Gtid_Set（从库当前执行到的GTID事务）
"root@localhost Mon Nov 23 16:16:40 2015 16:16:40 [(none)]>show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host: 192.168.1.28
Master_User: repl
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: mybinlog.000006
Read_Master_Log_Pos: 8220
Relay_Log_File: mysql-relay-bin.000005
Relay_Log_Pos: 5067
Relay_Master_Log_File: mybinlog.000006
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
……
Master_UUID: a0475f56-8dd2-11e5-aa53-08002722e892
Master_Info_File: /data/mysql/mysql3306/data/https://www.doczj.com/doc/da3912647.html,
SQL_Delay: 0
SQL_Remaining_Delay: NULL
Slave_SQL_Running_State: Slave has read all relay log; waiting for the slave I/O thread to update it
Master_Retry_Count: 86400
Master_Bind:
Last_IO_Error_Timestamp:
Last_SQL_Error_Timestamp:
Master_SSL_Crl:
Master_SSL_Crlpath:
Retrieved_Gtid_Set: a0475f56-8dd2-11e5-aa53-08002722e892:6-32
Executed_Gtid_Set: 5a888928-8dcc-11e5-aa2a-080027918f7c:1-4,
a0475f56-8dd2-11e5-aa53-08002722e892:1-32
Auto_Position: 1
1 row in set (0.00 sec)
到此基于GTID模式的主从复制构建完成。
美河学习在线https://www.doczj.com/doc/da3912647.html, MySQL主从复制 MySQL主从复制、搭建、状态检查、中断排查及备库重做 本文档主要对MySQL主从复制进行简单的介绍，包括原理简介、搭建步骤、状态检查、同步中断及排查、备库重建。
目录 一、MySQL主从复制概述 (2) 1、主从复制简介 (2) 2、主从复制原理、机制 (2) 3、主从复制原理图 (3) 二、MySQL主从复制搭建 (4) 1、Master端配置部署 (4) 2、Slave端配置部署 (4) 3、建立主从同步 (4) 三、主从复制状态检查及异常处理 (6) 1、主从复制状态检查 (6) 2、IO_thread异常 (7) 3、sql_thread异常 (8) 4、主从复制延迟 (9)
一、MySQL主从复制概述 1、主从复制简介 MySQL主从复制就是将一个MySQL实例（Master）中的数据实时复制到另一个MySQL实例(slave)中，而且这个复制是一个异步复制的过程。 实现整个复制操作主要由三个进程完成的，其中两个进程在Slave（sql_thread和IO_thread），另外一个进程在 Master（IO进程）上。 2、主从复制原理、机制 要实施复制，首先必须打开Master端的binary log（bin-log）功能，否则无法实现。因为整个复制过程实际上就是Slave从Master端获取该日志然后再在自己身上完全顺序的执行日志中所记录的各种操作。 复制的基本过程如下： 1)、Slave上面的IO_thread连接上Master，并请求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容； 2)、Master接收到来自Slave的IO_thread的请求后，通过负责复制的IO进程根据请求信息读取制定日志指定位置之后的日志信息，返回给Slave 的IO_thread。返回信息中除了日志所包含的信息之外，还包括本次返回的信息已经到Master端的bin-log file的以及bin-log pos； 3)、Slave的IO_thread接收到信息后，将接收到的日志内容依次添加到Slave端的relay-log文件的最末端，并将读取到的Master端的 bin-log的文件名和位置记录到master-info文件中，以便在下一次读取的时候能够清楚的告诉Master“我需要从某个bin-log的哪个位置开始往后的日志内容，请发给我”； 4)、Slave的Sql_thread检测到relay-log中新增加了内容后，会马上解析relay-log 的内容成为在Master端真实执行时候的那些可执行的内容，并在本数据库中执行。
一：MySQL复制： MySQL复制简介： 将master服务器中主数据库的ddl和dml操作通过二进制日志传到slaves服务器上，然后在master服务器上将这些日志文件重新执行，从而使得slave服务器和master服务器上的数据信息保持同步。 Mysql复制的原理： 将数据分布到多个系统上去，是通过将Mysql的某一台master主机的数据复制到其它（slave）主机上，并重新执行一遍来实现的； 复制过程中一个服务器充当master服务器，而一台或多台其它服务器充当slave服务器。master服务器将更新写入二进制日志文件，并维护文件的一个索引以跟踪日志循环。 这些日志可以记录发送到slave服务器的更新。当一个slaves服务器连接master服务器时，它通知master服务器从服务器在日志中读取的最后一次成功更新的位置。slave服务器接收从那时起发生的任何更新，然后封锁并等待master服务器通知新的更新。 mysql复制的优点： 在slave服务器上执行查询操作，降低master服务器的访问压力 当master服务器上出现了问题可以切换到slave服务器上，不会造成访问中断等问题 在slave服务器上进行备份，以避免备份期间影响master服务器的服务使用及日常访问
Mysql自身的复制功能：是构建大型、高性能应用程序的基础。 mysql支持的复制类型： 基于语句的复制：在主服务器上执行的SQL语句，在从服务器上执行同样的语句。MySQL默认采用基于语句的复制，效率比较高。一旦发现没法精确复制时，会自动选着基于行的复制。 基于行的复制：把改变的内容复制过去，而不是把命令在从服务器上执行一遍. 从mysql5.0开始支持 混合类型的复制:：默认采用基于语句的复制，一旦发现基于语句的无法精确的复制时，就会采用基于行的复制。 MySQL复制技术的特点： 数据分布(Data distribution ) 备份(Backups) 负载平衡(load balancing) 高可用性和容错性High availability and failover 复制的工作过程： master将改变记录到二进制日志(binary log)中（这些记录叫做二进制日志事件，binary log events）； slave将master的binary log events拷贝到它的中继日志(relay log)； slave重做中继日志中的事件，将改变反映它自己的数据。
前言 作为一名编程人员，对MySQL一定不会陌生，尤其是互联网行业，对MySQL的使用是比较多的。对于求职者来说，MySQL又是面试中一定会问到的重点，很多人拥有大厂梦，却因为MySQL败下阵来。实际上，MySQL并不难，今天这份最全的MySQL总结，助你向大厂“开炮”，面试不再被MySQL难倒。 注意：关于MySQL的内容整理，包括了面试题、学习笔记、使用文档以及Xmind思维图几个部分，需要高清完整版的请转发+关注，然后私信回复“666”获得免费领取方式 01、MySQL 面试题集合总结 1.1 MySQL 面试题（基础部分）： ?drop、truncate、delete区别 ?数据库三范式是什么? ?union和union all有什么不同? ?char、varchar2、varchar有什么区别？ ?合并查询有哪些？ ?SQL语句执行顺序 ?null的含义 ?MySQL、SqlServer、oracle写出字符存储、字符串转时间 ?update语句可以修改结果集中的数据吗？ ?B树和B+树的区别 ?你建过索引吗? 建索引的原则 ?索引的类型, 如主键索引 ?查看SQL执行计划
?有十万条数据, 写SQL语句查询其中某字段较大值的几条数据 ?子查询与关联查询的区别 ?MySQL InnoDB、Mysaim的特点？ ?乐观锁和悲观锁的区别？？ ?行锁和表锁的区别？ ?数据库隔离级别是什么？有什么作用？ ?MySQL主备同步的基本原理。 ?如何优化数据库性能（索引、分库分表、批量操作、分页算法、升级硬盘SSD、业务优化、主从部署） ?SQL什么情况下不会使用索引（不包含，不等于，函数） ?一般在什么字段上建索引（过滤数据最多的字段） ?MySQL，B+索引实现，行锁实现，SQL优化 ?如何解决高并发减库存问题 ?数据库事务的几种粒度 1.2 MySQL 面试题（实战部分）： ?数据库三范式，根据秒杀场景设计数据表 ?数据库的主从复制 ?死锁怎么解决 ?mysql并发情况下怎么解决（通过事务、隔离级别、锁） ?触发器的作用？ ?什么是存储过程？用什么来调用？ ?存储过程的优缺点？
主从复制的原理： 分为同步复制和异步复制，实际复制架构中大部分为异步复制。 复制的基本过程如下： 1)、Slave上面的IO进程连接上Master，并请求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容； 2)、Master接收到来自Slave的IO进程的请求后，通过负责复制的IO进程根据请求信息读取制定日志指定位置之后的日志信息，返回给Slave 的IO进程。返回信息中除了日志所包含的信息之外，还包括本次返回的信息已经到Master端的bin-log文件的名称以及bin-log的位置； 3)、Slave的IO进程接收到信息后，将接收到的日志内容依次添加到Slave端的relay-log文件的最末端，并将读取到的Master端的bin-log的文件名和位置记录到master-info文件中，以便在下一次读取的时候能够清楚的告诉Master“我需要从某个bin-log的哪个位置开始往后的日志内容，请发给我”； 4)、Slave的Sql进程检测到relay-log中新增加了内容后，会马上解析relay-log的内容成为在Master端真实执行时候的那些可执行的内容，并在自身执行。 Mysql为了解决这个风险并提高复制的性能，将Slave端的复制改为两个进程来完成。提出这个改进方案的人是Y ahoo!的一位工程师“Jeremy Zawodny”。这样既解决了性能问题，又缩短了异步的延时时间，同时也减少了可能存在的数据丢失量。当然，即使是换成了现在这样两个线程处理以后，同样也还是存在slave 数据延时以及数据丢失的可能性的，毕竟这个复制是异步的。只要数据的更改不是在一个事物中，这些问题都是会存在的。如果要完全避免这些问题，就只能用mysql的cluster来解决了。不过mysql的cluster是内存数据库的解决方案，需要将所有数据都load到内存中，这样就对内存的要求就非常大了，对于一般的应用来说可实施性不是太大。 复制常用架构 Mysql复制环境90%以上都是一个Master带一个或者多个Slave的架构模式，主要用于读压力比较大的应用的数据库端廉价扩展解决方案。因为只要master和slave的压力不是太大（尤其是slave端压力）的话，异步复制的延时一般都很少很少。尤其是自slave端的复制方式改成两个进程处理之后，更是减小了slave端的延时。而带来的效益是，对于数据实时性要求不是特别的敏感度的应用，只需要通过廉价的pc server来扩展slave的数量，将读压力分散到多台slave的机器上面，即可解决数据库端的读压力瓶颈。这在很大程度上解决了目前很多中小型网站的数据库压力瓶颈问题，甚至有些大型网站也在使用类似方案解决数据库瓶颈。 Mysql主从复制配置过程： 环境：master: 192.168.0.3 Slave: 192.168.0.4 Mysql版本为5.0.67（编译安装） database: eric 1.Master服务器启动mysql， a)#mysql –uroot –proot b)创建一个有复制权限的用户，只限slave远程连接访问. i. mysql>grant replication slave on *.* to replication@192.168.0.4
Mysql 数据库主主（master-master）同步方案 一、MySQL同步概述 1.MySQL数据的复制的基本介绍 目前MySQL数据库已经占去数据库市场上很大的份额，其一是由于MySQL数据的开源性和高性能，当然还有重要的一条就是免费~不过不知道还能免费多久，不容乐观的未来，但是我们还是要能熟练掌握MySQL数据的架构和安全备份等功能，毕竟现在它还算是开源界的老大吧！ MySQL数据库支持同步复制、单向、异步复制，在复制的过程中一个服务器充当主服务，而一个或多个服务器充当从服务器。主服务器将更新写入二进制日志文件，并维护文件的一个索引以跟踪日志循环。这些日志可以记录发送到从服务器的更新。当一个从服务器连接主服务器时，它通知主服务器从服务器在日志中读取的最后一次成功更新的位置。从服务器接收从那时起发生的任何更新，然后封锁并等待主服务器通知新的更新。 请注意当你进行复制时，所有对复制中的表的更新必须在主服务器上进行。否则，你必须要小心，以避免用户对主服务器上的表进行的更新与对从服务器上的表所进行的更新之间的冲突。 单向复制有利于健壮性、速度和系统管理： 健壮性：主服务器/从服务器设置增加了健壮性。主服务器出现问题时，你可以切换到从服务器作为备份。
速度快：通过在主服务器和从服务器之间切分处理客户查询的负荷，可以得到更好的客户响应时间。SELECT查询可以发送到从服务器以降低主服务器的查询处理负荷。但修改数据的语句仍然应发送到主服务器，以便主服务器和从服务器保持同步。如果非更新查询为主，该负载均衡策略很有效，但一般是更新查询。 系统管理：使用复制的另一个好处是可以使用一个从服务器执行备份，而不会干扰主服务器。在备份过程中主服务器可以继续处理更新。 2.MySQL数据复制的原理 MySQL复制基于主服务器在二进制日志中跟踪所有对数据库的更改(更新、删除等等)。因此，要进行复制，必须在主服务器上启用二进制日志。 每个从服务器从主服务器接收主服务器已经记录到其二进制日志的保存的更新，以便从服务器可以对其数据拷贝执行相同的更新。 认识到二进制日志只是一个从启用二进制日志的固定时间点开始的记录非常重要。任何设置的从服务器需要主服务器上的在主服务器上启用二进制日志时的数据库拷贝。如果启动从服务器时，其数据库与主服务器上的启动二进制日志时的状态不相同，从服务器很可能失败。 将主服务器的数据拷贝到从服务器的一个途径是使用LOAD DATA FROM MASTER语句。请注意LOAD DATA FROM MASTER目前只在
MySQL主从同步原理+部署 一.主从的作用： 1.可以当做一种备份方式 2.用来实现读写分离，缓解一个数据库的压力 二.MySQL主从备份原理 master 上提供binlog , slave 通过 I/O线程从 master拿取 binlog,并复制到slave的中继日志中 slave 通过 SQL线程从 slave的中继日志中读取binlog ,然后解析到slave中 部署主从环境：主服务器：192.168.1.110（编译好的MySQL5.1版本的数据库）从服务器：192.168.1.120（编译好的MySQL5.1版本的数据库） （温馨提示：主和从数据库版本必须是一样。或者主库的数据库版本必须比从库高,不然会导致很多故障的发生。） 三：生产环境应用MySQL主从同步场景： 1.一般用主库做为提供业务用户写操作（比如：在互联网上写一条微博，这时候就会 写到mysql数据库的主库中） 2.一般用从库做为提供业务用户读操作（比如：在互联网上，我想看一条微博，这时 候里面提供数据就是MySQL数据库的从库中。） (1)在主服务器（192.168.1.110）上操作。 [root@Jiechao ~]# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:0C:29:5E:6F:A7 inet addr:192.168.1.110 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::20c:29ff:fe5e:6fa7/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:141354 errors:0 dropped:0 overruns:0 frame:0 TX packets:140807 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:142083379 (135.5 MiB) TX bytes:17815696 (16.9 MiB) Interrupt:193 Base address:0x2000 [root@Jiechao ~]# vi /etc/https://www.doczj.com/doc/da3912647.html,f [mysqld]在mysqld下添加以上两行。 server-id = 1 log-bin=jiechao-bin [root@Jiechao ~]# /etc/init.d/mysqld restart Shutting down MySQL[ OK ] Starting MySQL.[ OK ]
数据库读写分离方案及对比版本日期修改历史作者
目录 1概述 (3) 2背景 (3) 3数据库读写分离方案 (3) 3.1Oracle数据库几种常用的复制技术及特点 (3) 3.2异构数据库（Oracle+Mysql）+ GoldenGate (3) 3.2.1方案描述 (3) 3.2.2实现原理 (4) 3.3异构数据库（Oracle+Mysql）+ 其他复制技术 (6) 3.4同构数据库（Oracle）+ GoldenGate (6) 3.4.1方案描述 (6) 3.4.2实现原理 (7) 3.5同构数据库（Oracle）+ DataGuard (7) 3.6同构数据库（SqlServer2008 企业版） (7) 3.6.1实现原理 (8) 3.7同构数据库（Mysql5社区版） (8) 4方案对比 (9)
1概述 本文主要是描述SVC（统一客户视图）项目的数据库读写分离的几种解决方案及优缺点对比。2背景 为了能进一步提升SVC业务系统的服务质量水平、运行效率、系统健壮性稳定性及运行安全，信息中心提出了对SVC的架构进行调整升级，以满足目前及未来的建设需求。 为了缓解大并发的情况下对数据库造成的压力，方案中引入了缓存及数据库的读写分离的技术解决问题。这里针对数据库的读写分离方案有几种实现方式，这里主要是描述这几种方案，以及这几种方案的对比，最后根据具体的情况选择最适合的方案。 由于是比较重要的业务系统，数据量及访问量都比较大，数据的存储主要考虑Oracle、DB2、SQLServer等知名商业数据库厂商。考虑到实现的技术复杂度及运维难度这里主要推荐Oracle作为存储数据库。 3数据库读写分离方案 这里初步提议的数据库有两种，Oracle 11g与Mysql 5。 3.1O racle数据库几种常用的复制技术及特点 3.2异构数据库（Oracle+Mysql）+ GoldenGate 3.2.1方案描述 该方案使用的是异构数据库，其中主数据为Oracle双机热备，从数据库使用的是多台Mysql。主数据库可进行读写操作，主要是进行写操作，从数据库只能读操作。下面是该方案的逻辑架构图：
数据库管理员岗位的主要职责表述 本文是关于数据库管理员岗位的主要职责表述，仅供参考，希望对您有所帮助，感谢阅读。 数据库管理员岗位的主要职责表述1 职责： 1、负责生产数据库(MySQL/Redis/MongoDB等)的日常运维、稳定性保障、性能优化; 2、根据业务需求选型数据库存储方案，优化性能，实施集群迁移及扩容，提高业务高可用性和容灾能力; 3、制定数据库监控、备份、容灾策略，确保数据库服务的正常稳定运行和应急响应及时定位和排除数据库故障，并对数据库进行持续优化; 4、提供数据库开发支持，负责SQL代码的上线审核，优化; 5、参与开发数据库运维工具脚本; 6、配合研发制定数据库技术方案，分库分表策略，数据迁移方案。 任职资格 1、具有2年以上DBA实际工作经验,具有中大型互联网数据库运维和管理经验优先; 2、熟悉常用存储引擎的功能和特点以及主从复制原理和实践; 3、熟悉MySQLDBA数据库基本原理，深入理解引擎、事务、锁机制等内部工作原理及优化; 4、熟悉数据库容量规划和分库、分表设计方法，有数据库设计和支持经验，熟悉大数据集群及具有相关维护工作经验; 5、熟悉Linux操作系统，能熟练进行日常系统管理操作; 6、有memcache、redis、mongodb经验优先; 7、善于沟通，积极分享，具有良好的团队协作能力、高度敬业精神. 数据库管理员岗位的主要职责表述2 职责
1、负责数据库的日常操作、安装、配置、监控、负载均衡、实时备份、恢复和管理; 2、依据业务需求优化数据存储结构; 3、通过数据库的日常检查，对性能较差的SQL语句提出优化方案; 4、协助项目其他成员设计关键的SQL语句和触发器、存储过程、表等; 5、负责数据库架构设计、分布式缓存设计等，解决多种业务模式下的可扩展、高可用、负载均衡等关键技术问题. 任职要求 1、相关工作经验2年以上; 2、熟悉Linux系统，能编写Shell或python脚本; 3、掌握数据库的高可用、迁移、扩容、备份恢复、性能监控; 4、熟悉Oracle、Mysql、Sql Server 数据库运行机制、体系架构，熟悉表结构和SQL优化; 5、熟练掌握Oracle数据库维护，能对业务需求和故障进行及时响应和处理，能解决Oracle RAC和DataGuard的故障; 6、熟练掌握MySQ数据库维护;掌握第三方配套工具Mycat、MMM、MHA等原理和实现及其故障排除; 7、熟悉Sql Server数据库维护. 数据库管理员岗位的主要职责表述3 职责： 1.负责全行数据库的日常维护，包括故障排查、性能优化、数据库升级或迁移; 2.负责全行数据库备份规划管理，包括数据库备份配置、故障处理、备份有效性校验。 3.负责全行数据库相关故障的排查、处理、优化，并且提出针对性的预防措施。 4.负责规划全行数据库架构设计方案和实施优化。 任职条件：
mysql数据库复制维护方法 编写人：胡家惠 日期：2007-9-26 数商的数据库服务器采用一主两从的结构，即一台主数据库服务器，两台从数据库服务器，主服务器负责读写，从服务器只能读取。以下例子中假设主服务器的IP地址是：172.20.16.204。从服务器的IP地址分别是：172.20.16.205，172.20.16.214。主服务器上更新的数据将通过mysql的复制功能复制到其它两台从服务器上，复制是异步进行的，延迟时间正常在3秒左右，如果是小数据量的更新操作，延迟时间将会更小，估计在1秒以下，完全能满足应用的需求。Web 服务器对数据库的访问负载将同时分布到这三台服务器上，从测试的情况看，主服务器的负载明显比从服务器的负载大，一个主要的原因是主服务器负责读写，而从服务器只分配一些查询的负载。 Mysql数据库复制维护主要包括：日常监控和维护，主从切换，从服务器拷贝，根据一个最可靠的从服务器数据生成另外一个从服务器，并把这个最可靠的从服务器升级为主服务器。目标就是当数据库出现故障时，能尽快的修复，最小化故障时间。 一、日常监控和维护 日常监控和维护的目的就是监控mysql复制进程的运行情况，解决发生的故障问题，保证主从服务器数据的一致性。 以下是用作日常监控的几条命令，说明如下： Show master status; 显示主服务器当前复制进程所处的bin文件名和位置 Show slave status\G; 显示从服务器复制进程的状态 Slave stop; 在从服务器上停止复制进程 Slave start; 在从服务器上启动复制进程 Set global sql_slave_skip_counter=1; 跳过一个错误的位置 Change master to master_log_file='mysql-bin.000001',master_log_pos=98; 改变到指定的日志位置点：日志文件mysql-bin.000001，位置98 示例： mysql> show slave status\G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 172.20.16.204
一、主从配置的原理: MySQL的 Replication 是一个异步的复制过程，从一个 MySQL instace(我们称之为 Master)复制到另一个MySQL instance(我们称之 Slave)。在 Master 与 Slave之间的实现整个复制过程主要由三个线程来完成，其中两个线程(Sql 线程和IO线程)在 Slave 端，另外一个线程(IO线程)在 Master端。 要实现MySQL 的Replication ，首先必须打开Master 端的Binary Log(MySQL-bin.xxxxxx)功能，否则无法实现。因为整个复制过程实际上就是Slave从Master端获取该日志然后再在自己身上完全顺序的执行日志中所记录的各种操作。打开 MySQL 的 Binary Log 可以通过在启动 MySQL Server 的过程中使用“—log-bin”参数选项，或者在 https://www.doczj.com/doc/da3912647.html,f 配置文件中的 MySQLd 参数组([MySQLd]标识后的参数部分)增加“log-bin”参数项。 MySQL 复制的基本过程如下： 1. Slave 上面的IO线程连接上 Master，并请求从指定日志文件的指定位置(或者从最开始的日志)之后的日志内容; 2. Master 接收到来自 Slave 的 IO 线程的请求后，通过负责复制的 IO线程根据请求信息读取指定日志指定位置之后的日志信息，返回给 Slave 端的 IO 线程。返回信息中除了日志所包含的信息之外，还包括本次返回的信息在 Master 端的 Binary Log 文件的名称以及在 BinaryLog 中的位置; 3. Slave 的 IO 线程接收到信息后，将接收到的日志内容依次写入到 Slave 端的RelayLog文件(MySQL-relay-bin.xxxxxx)的最末端，并将读取到的Master 端的bin-log的文件名和位置记录到master-info文件中，以便在下一次读取的时候能够清楚的高速Master“我需要从某个bin-log的哪个位置开始往后的日志内容，请发给我” 4. Slave 的 SQL 线程检测到 Relay Log 中新增加了内容后，会马上解析该 Log 文件中的内容成为在 Master端真实执行时候的那些可执行的 Query 语句，并在自身执行这些 Query。这样，实际上就是在 Master 端和 Slave端执行了同样的 Query，所以两端的数据是完全一样的。
mysql双主架构方案设计 mysql支持单向、异步复制，复制过程中一个服务器充当主服务器，而一个或多个其他服务器充当从服务器。主服务器将更新写入二进制日志文件，并维护日志文件的一个索引以跟踪日志循环。当一个从服务器连接到主服务器时，它通知主服务器从服务器在日志中读取的最后一次成功更新的位置。从服务器接受从那时起发生的任何更新，然后封锁并等待主服务器通知下一次更新。 mysql_proxy，是处在应用端和数据库服务器之间的程序，支持嵌入性脚本语言Lua。mysql_proxy可以用于分析、监控和转换通信数据，支持数据库层负载均衡和读写分离的功能。 1mysql双主架构设计
Client... 架构说明： ●mysql1和mysql2互为主从关系，数据库间通过复制（Replication）实现数据的同步。 ●client端直接连接mysql_proxy，通过mysql_proxy实现到数据库的负载均衡和读写分 离； ●mysql高可用性架构，常用的有主从复制、主主复制及双主从等形式，基于业务的实际 需要进行选择考虑。 2mysql主从复制配置 2.1主从配置需要注意的点 (1)主从服务器操作系统版本和位数一致；
(2) Master和Slave数据库的版本要一致； (3) Master和Slave数据库中的数据要一致； (4) Master开启二进制日志，Master和Slave的server_id在局域网内必须唯一； 2.2主从配置的步骤 2.2.1M aster上的配置 (1) 安装数据库； (2) 修改数据库配置文件，指明server_id，开启二进制日志(log-bin)； (3) 启动数据库，查看当前是哪个日志，position号是多少； (4) 登录数据库，授权数据复制用户（IP地址为从机IP地址，如果是双向主从，这里的还需要授权本机的IP地址，此时自己的IP地址就是从IP地址)； (5) 备份数据库（记得加锁和解锁）； (6) 传送备份数据到Slave上； (7) 启动数据库； 以下步骤，为单向主从搭建成功，想搭建双向主从需要的步骤： (1) 登录数据库，指定Master的地址、用户、密码等信息（此步仅双向主从时需要）； (2) 开启同步，查看状态； 2.2.2S lave上的配置 (1) 安装数据库； (2) 修改数据库配置文件，指明server_id（如果是搭建双向主从的话，也要开启二进制日志
手把手教你实现MySQL双机数据同步 假设目前有两台 MySQL 数据库服务器，如何实现这两台机器的数据同步问题？很多朋友一开始接触MySQL双机同步需求的时候可能会感到不知道从哪里入手，事实上这是MySQL本身就支持的功能之一。本文提供有关MySQL主从同步的初步思路，供大家参考。 AD： 编者按：很多朋友一开始接触MySQL双机同步需求的时候可能会感到不知道从哪里入手，事实上这是MySQL本身就支持的功能之一。本文提供有关MySQL主从同步的初步思路，供大家参考。 一.需求问题 假设目前有两台 MySQL 数据库服务器，如何实现这两台机器的数据同步问题？即在一台机器上修改数据库后，另一台机器会同步更新所修改的信息。 二.解决方案 查资料发现 MySQL 支持单向，异步复制，复制过程中一个服务器充当主服务器，而另一个或多个其他服务器充当从服务器。 原理是这样的： 主服务器将更新写入二进制日志文件，并维护文件的一个索引来跟踪日志循环。这些日志可以记录发送到从服务器的更新。当一个从服务器连接主服务器时，它通知主服务器从服务器在日志中读取的最后一次成功更新的位置。从服务器接受从那时起发生的任何更新，然后封锁并等待主服务器通知新的更新。 2.1 测试环境 1.Master : 19 2.168.7.67 (CentOS 5.5 x86_64 ) MySQL Version : 5.0.77 2.Slave: 192.168.56.103 (CentOS 5.3 i386) MySQL Version : 5.0.4 5 备注： Master 和 slave 端的 MySQL 版本最好要一样的，或者 Master 端的版本高于Slave 端 2.2 配置过程 2.2.1 Master 端设置
赵班长原创作品系统运维之MySQL DBA UNIXHOT开源社区
赵班长原创作品 系统运维之MySQL DBA 时间：2010年6月3日 姓名：赵班长 版本：1.0 实验目的：通过实验掌握MySQL数据库相关应用。 实验环境：Red Hat Enterprise Linux Server release5.3(Tikanga) 实验简介： UNIXHOT开源社区致力于为想成为系统运维工程师、系统集成工程师、系统架构师、MySQL DBA 和Oracle DBA的互联网朋友们创造一个开源的、共享的、完整的、创新的、一站式的学习和交流平台。欢迎大家加入，让我们成为一个圈子。 注意：本文为从入门到精通的一个一站式学习文档，如果想更深入的学习MySQL，请参考MySQL 的官方文档，也可以在UnixHot开源论坛讨论学习。 此文档持续更新中......学习讨论请进-->【MySQL DBA】版块 实验步骤： 第一章MySQL概述 第二章MySQL源码安装 第三章MySQL Replication 第四章MySQL Proxy 第五章MySQL Cluster 实验内容：
赵班长原创作品MySQL是最流行的开放源码SQL数据库管理系统，它是由MySQL AB公司开发、发布并支持的。它的插入式存储引擎可以让使用者根据实际应用使用不同的存储 1.2MySQL相关链接 MySQL官方网站：https://www.doczj.com/doc/da3912647.html,/ MySQL社区版本下载地址：https://www.doczj.com/doc/da3912647.html,/downloads/mysql/ MySQL中文文档：https://www.doczj.com/doc/da3912647.html,/doc/refman/5.1/zh/index.html 第二章MySQL源码安装 2.1解压并编译安装 [root@MySQL-Master src]#tar zxvf mysql-5.1.45.tar.gz [root@MySQL-Master src]#cd mysql-5.1.45 [root@MySQL-Master mysql-5.1.45]#./configure--prefix=/usr/local/mysql\ --localstatedir=/unixhot/mysql--enable-assembler--with-system-type="RedHat Enterprise"\ --with-client-ldflags=-all-static--with-mysqld-ldflags=-all-static\ --with-pthread--enable-static--with-big-tables--without-ndb-debug\ --with-charset=utf8--with-extra-charsets=all\ --without-debug--enable-thread-safe-client--enable-local-infile--with-plugins=max [root@MySQL-Master mysql-5.1.45]#make&&make install 2.2安装参数介绍 --prefix=/usr/local/mysql//主程序安装目录
最近由于一个简单需求必须保证多个数据库一致性，因此不得不用到数据库之间的同步。mysql数据库同步，自己本身就做的很好，我们只需要简单设置就可以搞定了，并且加上phpmyadmin就更简单了。这里，我们主要介绍一下怎样通过phpmyadmin辅助设置主从数据库同步。 一、实现同步的原理： 在主数据库与从数据库之间的实现整个复制过程主要由三个线程来完成，其中两个线程(Sql线程和IO线程)在从数据库端，另外一个线程(IO线程)在主数据库端。 注意： 1.要实现同步，必须先启动主数据库（相当于开启一个服务，等待其他数据库来连接），然后在启动从数据库 2.数据库的版本要一致 二、具体步骤 1.打开主数据库，找到复制功能 选择自己需要同步的数据（或者排除的数据库）生成一段代码，打开住数据库的my.conf（默认：/etc/mysql/https://www.doczj.com/doc/da3912647.html,f），在配置文件最后加上一行 [mysqld]，再加上phpmyadmin生成的代码。即： [mysqld] server-id=3936765 log-bin=mysql-bin
log-error=mysql-bin.err binlog_ignore_db=test 然后重启数据库 /etc/init.d/mysql restart 现在回到phpmyadmin的复制界面，我们可以看到如图则表示主数据库已经配置成功 现在我们就可以添加复制的用户了，可根据自己的需求添加用户， 注意：如果我们添加的用户的【主机】不是127.0.0.1的就必须修改我们的mysql 配置文件，因为mysql默认安装是只允许127.0.0.1连接的。我们需要找到以下两句话，然后注释掉就可以了，当然需要重启mysql #skip-external-locking #bind-address=127.0.0.1 2.现在配置从数据库 同样的，进入从数据库的phpmyadmin的复制界面，选择【从复制】的配置。进入之后，phpmyadmin会默认生成一个随机的线程ID（也可以自己写一个），跟配置主数据库一样，在从数据库的配置文件中加入 [mysqld] server-id=1375673884
高性能Mysql主从架构的复制原理及配置详解 1 复制概述 Mysql内建的复制功能是构建大型，高性能应用程序的基础。将Mysql的数据分布到多个系统上去，这种分布的机制，是通过将Mysql的某一台主机的数据复制到其它主机（slaves）上，并重新执行一遍来实现的。复制过程中一个服务器充当主服务器，而一个或多个其它服务器充当从服务器。主服务器将更新写入二进制日志文件，并维护文件的一个索引以跟踪日志循环。这些日志可以记录发送到从服务器的更新。当一个从服务器连接主服务器时，它通知主服务器从服务器在日志中读取的最后一次成功更新的位置。从服务器接收从那时起发生的任何更新，然后封锁并等待主服务器通知新的更新。 请注意当你进行复制时，所有对复制中的表的更新必须在主服务器上进行。否则，你必须要小心，以避免用户对主服务器上的表进行的更新与对从服务器上的表所进行的更新之间的冲突。 1.1 mysql支持的复制类型： （１）：基于语句的复制：在主服务器上执行的SQL语句，在从服务器上执行同样的语句。MySQL默认采用基于语句的复制，效率比较高。 一旦发现没法精确复制时，会自动选着基于行的复制。 （２）：基于行的复制：把改变的内容复制过去，而不是把命令在从服务器上执行一遍. 从mysql5.0开始支持 （３）：混合类型的复制: 默认采用基于语句的复制，一旦发现基于语句的无法精确的复制时，就会采用基于行的复制。 1.2 . 复制解决的问题 MySQL复制技术有以下一些特点： (1) 数据分布 (Data distribution ) (2) 负载平衡(load balancing) (3) 备份(Backups) (4) 高可用性和容错行 High availability and failover 1.3 复制如何工作 整体上来说，复制有3个步骤：
Mysql双机互备热备,自动切换 Mysql双机互备热备,自动切换 星期日, 12/20/2009 - 22:15 — wdlinux 作者:wdlinux https://www.doczj.com/doc/da3912647.html, QQ:12571192 我的Linux,开源技术,应用方案,集群架构,高可用,负载均衡,分流,性能优化 欢迎转载,转载时请务必以超链接形式标明文章原始出处和作者信息及本声明. Mysql双机互备热备 在实际的应用中，数据库是非常重要和关键的一个环节。在保障数据库安全的同时，提高应用性和缩短出故障后的恢复时间，也同等重要。特别是在一些持续性和实时性要求高的应用中，故障一小时，可能会让你损失几千到几万甚至更高。本方案致力于数据库实时备份，并且在故障发生后以最短的时间恢复和修复 在mysql数据库的备份应用中，主从复制结构是应用的比较广泛，数据同步和实时性都很高，基本上能满足大部分的需求。 本方案基于主从复制结构的基础上，当主库出现故障时，从
库能自动接管主库的功能，向外提供服务，且将自身设置为主库，将这个故障时间和影响缩短至最小，5秒内可切换完成。待原主库修复后，会自动进入从库的备份角色，如此循环。 在本方案的实现中，有两种方法且均基于mysql的主从结构中 1 高可用(High Availability)HA集群，用heartbeat实现及增加了故障后的恢复功能 2 同样是高可用，只是是自己编写脚本程序来监控，切换，恢复 在方法1中，使用稳定的heartbeat开源软件实现，但此方法，需要多一个IP对外访问，同时在监控上，是监控机器的状态而不是mysql，有些情况下，机器是好的但mysql服务挂了，这种情况下就不准确了。不过可以修改监控方式或增加对mysql服务的监控 方法2中，可以不用增加一个对外IP，同时在监控上，可以直接监控mysql的服务，至于稳定性，有待测试。此方法中还有一个问题，就是提供给客户端的数据库连接IP，因为切换后，IP也就变了。如果说更改程序，那不现实。所以，这里可以用域名，不过仍然需要修改域名的IP指向或是修改客户机的hosts文件。本文使用的是修改DNS的方法，因为DNS是自己配置的，可以灵活操作。
常用命令: service mysqld start service iptables stop mysql–u root 主从复制 概念 影响MySQL-A数据库的操作，在数据库执行后，都会写入本地的日志系统A中。
假设，实时的将变化了的日志系统中的数据库事件操作，在MYSQL-A的3306端口，通过网络发给MYSQL-B。 MYSQL-B收到后，写入本地日志系统B，然后一条条的将数据库事件在数据库中完成。 那么，MYSQL-A的变化，MYSQL-B也会变化，这样就是所谓的MYSQL的复制，即MYSQL replication。 在上面的模型中，MYSQL-A就是主服务器，即master，MYSQL-B就是从服务器，即slave。 日志系统A，其实它是MYSQL的日志类型中的二进制日志，也就是专门用来保存修改数据库表的所有动作，即bin log。【注意MYSQL会在执行语句之后，释放锁之前，写入二进制日志，确保事务安全】 日志系统B，并不是二进制日志，由于它是从MYSQL-A的二进制日志复制过来的，并不是自己的数据库变化产生的，有点接力的感觉，称为中继日志，即relay log。 可以发现，通过上面的机制，可以保证MYSQL-A和MYSQL-B的数据库数据一致，但是时间上肯定有延迟，即MYSQL-B的数据是滞后的。 【即便不考虑什么网络的因素，MYSQL-A的数据库操作是可以并发的执行的，但是MYSQL-B 只能从relay log中读一条，执行下。因此MYSQL-A的写操作很频繁，MYSQL-B很可能跟不上。】 解决问题 数据如何不被丢失 备份 读写分离 数据库负载均衡 高可用 服务器准备 192.168.110.177主服务器master 192.168.110.178从服务器slave 修改主(master)服务器 vi/etc/https://www.doczj.com/doc/da3912647.html,f新增以下内容 server_id=177###服务器id log-bin=mysql-bin###开启日志文件
MySQL丢数据及主从数据不一致的场景 1.相关知识点： innodb_flush_log_at_trx_commit innodb_flush_log_at_timeout sync_binlog relay log、relay log info、master info： master-info-repository relay-log-info-repository sync_relay_log sync_master_info sync_relay_log_info 原文地址：https://www.doczj.com/doc/da3912647.html,/25704976/viewspace-1318714/ 随着对MySQL的学习，发现了MySQL的很多问题，最重要的就是丢数据的问题。对于丢数据问题，我们应该了解丢数据的场景，这样在以后的学习中多考虑如何去避免及解决这些问题。 2.MySQL数据库层丢数据场景 本节我们主要介绍一下在存储引擎层上是如何会丢数据的。 2.1.InnoDB丢数据 InnoDB支持事务，同Oracle类似，事务提交需要写redo、undo。采用日志先行的策略，将数据的变更在内存中完成，并且将事务记录成redo，顺序的写入redo日志中，即表示该事务已经完成，就可以返回给客户已提交的信息。但是实际上被更改的数据还在内存中，并没有刷新到磁盘，即还没有落地，当达到一定的条件，会触发checkpoint，将内存中的数据（page）合并写入到磁盘，这样就减少了离散写、IOPS，提高性能。 在这个过程中，如果服务器宕机了，内存中的数据丢失，当重启后，会通过redo日志进行recovery重做。确保不会丢失数据。因此只要redo能够实时的写入到磁盘，InnoDB 就不会丢数据。 先来看一下innodb_flush_log_at_trx_commit这个参数： = 0 ：每秒 write cache & flush disk