mysql主从配置

一、首先两台服务器安装好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 | |

摘要 上一篇 : 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都创建拥有复制权限的账号

来自：http://www.osyunwei.com/archives/7269.html,改版 mysql主从复制 本文采用的是 centos6.5+mysql-5.6.23版本 之前在 windows7安装过主从复制,现在在linux实现主从复制 mysql安装方法: http://www.cnblogs.com/lin3615/p/4376224.html 配置: 配置MySQL主服务器（192.168.179.142) 从服务器两台(192.168.179.146,192.168.179.147) 数据库就以 test为例, // 从这里开始配置第一台从服务器 #建立一个MySQL主从数据库同步用户 lin3615,密码123456,并授予给192.168.179.146 登陆数据库，进入控制台 insert into mysql.user(Host,User,Password,ssl_cipher,x509_issuer,x509_subject) values('%','lin3615',password('123456'),'','',''); #刷新系统授权表 flush privileges; #授权用户lin3615 只能从 192.168.179.146 这个IP访问主服务器192.168.179.142上面的数据库 grant replication

前言：MySQL进行主主复制或主从复制的时候会在配置文件制定的目录下面产生相应的relay log，本文档总结这些相关参数的定义及解释。 1、什么是relay log The relay log, like the binary log, consists of a set of numbered files containing events that describe database changes, and an index file that contains the names of all used relay log files. The term “ relay log file” generally denotes an individual numbered file containing database events. The term “ relay log” collectively denotes the set of numbered relay log files plus the index file. Relay log files have the same format as binary log files and can be read using mysqlbinlog . 理解：relay log很多方面都跟binary

在生产环境中，我们的架构很多都是一主多从。比如一个主数据库服务器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的复制是基于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。此时，对复制没有影响。

刚处理完“挖矿”事件，在做最后一个MySQL NBU备份的时候，发现从库有问题，好奇的是怎么主从状态异常没有告警呢？先不管这么多了，处理了这个问题再完善告警内容。 一、错误信息 从库show slave status \G看到的错误信息如下： Slave_IO_Running: No Slave_SQL_Running: Yes Last_IO_Errno: 1236 Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Client requested master to start replication from impossible position; the first event 'mysql-bin.000081' at 480141113, the last event read from './mysql-bin.000081' at 4, the last byte read from './mysql-bin.000081' at 4.' 二、错误原因 这里看到从库的io_thread已经终止，错误编号是1236，具体是由于读取主库的binlog日志位置（ the first event 'mysql -bin. 000081 ' at

1.准备工作，2台服务器都安装最好一个版本的mysql 　　主：192.168.100.1 　　从：192.168.100.2 　　a.修改主数据库/etc/my.cnf,mysqld下添加。修改之后重启。 　　　　[mysqld] 　　　　server-id=1 　　　　log-bin=mysqlmaster-bin.log 　　b.修改从数据库/etc/my.cnf，mysqld下添加。修改之后重启 　　　　[mysqld] 　　　　server-id=2 　　　　log-bin=mysqlmaster-bin.log 2.主库操作 　　 ①主库创建用于主从复制的账户 　　　　mysql>create user sync@'192.168.100.2' identified by 'sync'; 　　　　mysql>grant replication slave on *.* to sync@'192.168.100.2'; 　　　　#注意 192.168.100.2为从库的ip地址，需要换成实际的。我设置的主从账户和密码都为sync，可以更换。 　　 ②.主库锁表，禁止再插入数据以获取主数据库二进制日志坐标。 　　　　mysql>flush tables with read lock; 　　 ③新开一个会话窗口，进入mysql库，执行 　　mysql> show master

保证主库和从库数据库数据一致 mysql主库MASTER配置(在my.cnf中加入以下配置): log-bin=master-bin binlog-do-db=test #需要同步的数据库名称 server-id=11 进行授权: grant replication slave on *.* to 'repl'@'192.168.1.110' identified by 'repl' with grant option; 重启mysql 查看master状态 show master status; mysql从库配置(在my.cnf中加入配置): server-id=12 master-host=192.168.1.104 master-user=repl master-password=repl master-port=3306 replicate-do-db=test #需要同步的数据库名称 #停止slave stop slave #更改日志同步点 CHANGE MASTER TO MASTER_HOST='192.168.1.104',MASTER_USER='repl', MASTER_PASSWORD='repl',MASTER_LOG_FILE='master-bin.000002',MASTER_POSITION=1134; #启动slave start slave