master

前言 数据库实时备份的需求很常见，MySQL本身提供了 Replication 机制，摘译官方介绍如下： MySQL Replication 可以将一个主数据库中的数据同步到一个或多个从数据库中。并且这个同步过程默认以异步方式工作，不需要保持主从数据库的实时连接（即允许连接中断）。同时允许自定义配置需同步的数据库及数据表。 MySQL Replication 的优点及应用场景如下： 1、通过 MySQL Replication 实现负载均衡与读写分离（主数据库仅更新，从数据库仅读取），提升数据库性能。 2、通过 MySQL Replication 实现数据的实时备份，保证数据安全。 3、通过 MySQL Replication 实现数据的离线分析（主数据库生成数据，从数据库分析计算不影响主数据库性能）。 4、数据分发。 MySQL Replication完整的官方文档请参阅： https://dev.mysql.com/doc/refman/5.7/en/replication.html 剑 http://www.cnblogs.com/wu-jian 工作原理 1、Master中的所有数据库变更事件写入Binary Log文件 2、当在Slave中执行“SLAVE START”命令时，开启Slave I/O Thread，并连接Master 3、Master侦测到Slave I

maridb（>10.0）主从复制 1.环境说明 测试环境 系统版本：Ubuntu 16.04.5 LTS内核版本：4.4.0-141-generic x86_64MariaDB版本：mysql Ver 15.1 Distrib 10.0.36-MariaDB主服务器：192.168.100.179 xyx-test01.lingda.com从服务器：192.168.100.70 xyx0001.lingda.com 官方： https://mariadb.com/kb/en/library/replication-overview/#standard-replication 2.MariaDB配置 /etc/mysql/mariadb.conf.d/50-server.cnf #通用配置 [mysqld]binlog-format=ROWlog-slave-updates=True # slave更新是否记入日志master-info-repository=TABLErelay-log-info-repository=TABLE # 此两项为打开从服务器崩溃二进制日志功能，信息记录在事物表而不是保存在文件sync-master-info=1 # 值为1确保信息不会丢失slave-parallel-threads=1 #同时启动多少个复制线程

一、首先两台服务器安装好mysql数据库环境 参照 linux rpm方式安装mysql5.1 https://www.cnblogs.com/sky-cheng/p/10564604.html 二、主库master上创建主从复制账号 mysql> grant replication slave,replication client on *.* to 'repl'@'%' identified by 'Zaq1xsw@'; Query OK, 0 rows affected, 1 warning (0.00 sec) mysql> use mysql; Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed mysql> select user,host from user; +---------------+-----------+ | user | host | +---------------+-----------+ | repl | % | | root | % | | mysql.session | localhost | |

目录 1. 是什么 2. 能干嘛 3. Redis主从复制讲解 (1). info replication:查看 目标redis 主从情况 (2) . 配从库不配主库 (3). 常用策略 (4). 复制原理 (5). 重要的哨兵模式 1. 是什么 行话：也就是我们所说的主从复制，主机数据更新后根据配置和策略自动同步到备机的 master/slave 机制，Master以写为主，Slave 以读为主 2. 能干嘛 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载 高可用基石：由于主从复制是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础 3. Redis主从复制讲解 (1). info replication:查看 目标redis 主从情况 (2) . 配从库不配主库 从库配置：slaveof 主库IP 主库端口 注：slaveof 进行配置的话，每次断开后都需要重新连接，除非配置进redis.conf文件中 一旦从库 跟随了

摘要 上一篇 : MySQL Replication 基础 　　　　　　 下一篇 MySQL Replication-MHA 　　一、主主复制 　　二、半同步复制 　　三、复制过滤器 　　四、总结 　　五、切分 　　　　待续 一、主主复制 　 　MySQL的主主复制通过互为主从来实现，此时负载均衡调度器较为容易实现，但是由于多台服务器都为Master，但是存在着严重的问题，需要慎重使用： 　　　　1. 数据不一致问题，无法解决，详情见paxos算法说明 　　　　2. auto_increment id问题 　　　　　　如何解决？以2台为例，一台用奇数，一台用偶数即可 　　配置步骤： 　　　　(1) 各节点使用一个唯一的server_id 　　　　(2) 都启动二进制日志和中继日志 　　　　(3) 创建拥有复制权限的用户账号 　　　　(4) 定义自动增长id字段的数值范围为奇数和偶数 　　　　(5) 互为主从，都启动复制线程 　　 　　演示如下： 　　 (1) Master和Slave修改配置，主要是以下参数 　　 log-bin=master-bin relay_log=relay_log auto_increment_offset=2 auto_increment_increment=2 server_id=1 　　 (2) Master和Slave都创建拥有复制权限的账号

1.1.1. If a crash happens thisconfiguration does not guarantee that the relay log info will be consistent 【环境的叙述性说明】 msyql5.6.14 【报错信息】 mysql的slave启动时，error.log中出现Warning警告： [Warning] Slave SQL: If a crash happensthis configuration does not guarantee that the relay log info will beconsistent, Error_code: 0 这条Warning信息对Mysql和MySQL复制功能没有不论什么影响。 【报错原因】 MySQL5.6版本号開始支持把master.info和relay-log.info的内容写入到mysql库的表中。 master.info--> mysql.slave_master_info relay-log.info--> mysql. slave_relay_log_info 同一时候在MySQL5.6版本号中，添加了 Slave crash-safe replication 功能，为了保证mysql的replication可以crash-safe。slave_master

在生产环境中，我们的架构很多都是一主多从。比如一个主数据库服务器M，两个从数据库服务器S1，S2同时指向主数据库服务器M。当主服务器M因为意外情况宕机，需要将其中的一个从数据库服务器（假设选择S1）切换成主数据库服务器，同时修改另一个从数据库（S2）的配置，使其指向新的主数据库（S1）。此外还需要通知应用修改主数据库的IP地址，如果可能，将出现故障的主数据库(M)修复或者重置成新的从数据库。通常我们还有其他的方案来实现高可用，比如MHA，MySQL Cluster，MMM，这些将在后续的文章中慢慢道来。现在我们先看简单的一主多从切换的情况。^_^ 下面详细介绍切换主从的操作步骤。 1.首先要确保所有的从数据库都已经执行了relay log中的全部更新，在每个从库上，执行stop slave io_thread,停止IO线程，然后检查show processlist的输出，直到看到状态是Slave has read all relay log; waiting for the slave I/O thread to update it，表示更新都执行完毕 S1(从库1操作)： mysql> stop slave io_thread; Query OK, 0 rows affected (0.06 sec) mysql> show processlist\G *************

现在不少公司都在用MySQL（master）-->MySQL（slave）的框架，当然也有一主多从的架构，这也是MySQL主从的一个延伸架构;当然也有的公司MySQL主主的架构，MySQL主主架构要是处理得不适当，会面临各种各样的问题，当然啦，每种数据库构架都有自己的优缺点，合适自己公司业务需求的且方便自己维护的架构都可以认为是理想的构架，当出现同步断开了，我们是不是一味的使用 --slave-skip-errors=[error_code] 来跳过错误代码呢？其实不是的，这样做可能会造成数据不一致的可能，下面我只针对MySQL Replication常见的错误进行说明及处理。 一、在master上更新一条记录时出现的故障 （ master与slave处理同步的情况下，binlog为row格式 ） 在slave库上，模拟slave少了一条数据，所以把id=6的记录在slave上先delete掉： root@mysql-slave> select * from test; +----+------+----------+ | id | name | code | +----+------+----------+ | 6 | aa | 10002011 | | 7 | bb | 10002012 | | 8 | cc | 10002013 | | 9 | dd | 10002014 |

原文请参照MySQL官方文档Reference Manual，版本5.6.10。 复制功能使得数据可以从一个MySQL数据库（master主库）复制到另一个或多个MySQL数据库（slave从库）。缺省情况下，复制是异步的，slave无需保持持久的连接来从master获得更新。这意味着更新能工作在远程连接，甚至是临时间断性的连接上，比如拨号连接服务。根据不同的配置，你能复制master上所有的数据库，或指定的数据库，甚至某一数据库中指定的数据表。 下面是关于复制功能，新手经常问到的问题。 1. slave必须要持久连接到master吗？ 不需要。slave可以关机或失去连接几小时甚至几天，然后重新连接获取更新。举例来说，你能在拨号连接网络上建立复制，而该拨号网络只有不定时或短时间的连接。这也意味着，在任何给定时间点，slave不能保证和master保持完全一致，除非你采取某些特别的措施。 为了保证能获取在slave失去连接时的更新，你不能从master上移除包含未完成复制内容的binary二进制日志文件。异步复制能维持工作的条件：slave能从最后一次读取事件的点继续读取binary二进制日志。 2. 复制必须要在master和slave上开启网络功能吗？ 是的，必须要在master和slave上开启网络功能。如果网络没有连接

MySQL的复制是基于binlog来实现的。 流程如下 涉及到三个线程，主库的DUMP线程，从库的IO线程和SQL线程。 1. 主库将所有操作都记录到binlog中。当复制开启时，主库的DUMP线程根据从库IO线程的请求将binlog中的内容发送到从库。 2. 从库的IO线程接受到主库DUMP线程发送的binlog事件后，将其写到本地的relay-log。 3. 从库的SQL线程重放relay-log中的事件。 实际上，在MySQL 4.0之前，复制只有两个线程，master和slave端各一个。在Slave端，该线程同时负责接收主库发来的binlog事件，也负责事件的重放，所以没有使用relay-log，这样容易导致，当binlog事件的重放速度较慢时，会影响binlog事件的接受。 复制的搭建 基本步骤如下： 1. 配置主库和从库 2. 创建复制的账号 3. 创建主库一致性快照 4. 根据主库的快照，建立从库 5. 开启复制 详细步骤如下 1. 配置主库和从库 主库 开启binlog并设置server-id [mysqld] log-bin=mysql-bin server-id=1 在一组复制结构中，每个服务器必须配置一个唯一的server-id。该值的有效范围为1~2 32 -1。 如果server-id设置为0的话，则MySQL会自动将它更改为1。此时，对复制没有影响。