mysql+centos7+主从复制
MYSQL(mariadb)
MariaDB数据库管理系统是MySQL的一个分支，主要由开源社区在维护，采用GPL授权许可。
开发这个分支的原因之一是：甲骨文公司收购了MySQL后，有将MySQL闭源的潜在风险，因此社区采用分支的方式来避开这个风险。
MariaDB的目的是完全兼容MySQL，包括API和命令行，使之能轻松成为MySQL的代替品。
方法1：yum安装mariadb
Red Hat Enterprise Linux/CentOS 7.0 发行版已将默认的数据库从 MySQL 切换到 MariaDB。
第一步：添加 MariaDB yum 仓库
1、首先在 RHEL/CentOS 和 Fedora 操作系统中添加 MariaDB 的 YUM 配置文件 MariaDB.repo 文件。
#编辑创建mariadb.repo仓库文件 vi /etc/yum.repos.d/MariaDB.repo
2、添加repo仓库配置 [mariadb] name = MariaDB baseurl = http://yum.mariadb.org/10.1/centos7-amd64 gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB gpgcheck=1
第二步：在 CentOS 7 中安装 MariaDB
2、当 MariaDB 仓库地址添加好后，你可以通过下面的一行命令轻松安装 MariaDB。
yum install MariaDB-server MariaDB-client -y
第三不，启动mariadb相关命令
mariadb数据库的相关命令是：
systemctl start mariadb #启动MariaDB
systemctl stop mariadb #停止MariaDB
systemctl restart mariadb #重启MariaDB
systemctl enable mariadb #设置开机启动
启动后正常使用mysql
systemctl start mariadb
初始化mysql
在确认 MariaDB 数据库软件程序安装完毕并成功启动后请不要立即使用。为了确保数据 库的安全性和正常运转，需要先对数据库程序进行初始化操作。这个初始化操作涉及下面 5 个 步骤。 ➢ 设置 root 管理员在数据库中的密码值(注意，该密码并非 root 管理员在系统中的密 码，这里的密码值默认应该为空，可直接按回车键)。 ➢ 设置 root 管理员在数据库中的专有密码。 ➢ 随后删除匿名账户，并使用 root 管理员从远程登录数据库，以确保数据库上运行的业 务的安全性。 ➢ 删除默认的测试数据库，取消测试数据库的一系列访问权限。 ➢ 刷新授权列表，让初始化的设定立即生效。
确保mariadb服务器启动后，执行命令初始化
mysql_secure_installation
初始化mysql
mysql基本命令
#修改mysql密码 MariaDB [(none)]> set password = PASSWORD('redhat123');
生产环境里不会死磕root用户，为了数据库的安全以及和其他用户协同管理数据库，就需要创建其他数据库账户，然后分配权限，满足工作需求。
MariaDB [(none)]> create user yuchao@'127.0.0.1' identified by 'redhat123';
MariaDB [(none)]> use mysql;
MariaDB [mysql]> select host,user,password from user where user=‘yuchao’;
切换普通用户yuchao，查看数据库信息，发现无法看到完整的数据库列表
[root@master ~]# mysql -uyuchao -p -h 127.0.0.1
MariaDB [(none)]> show databases;
数据库权限设置
mysql使用grant命令对账户进行授权，grant命令常见格式如下
grant 权限 on 数据库.表名 to 账户@主机名 对特定数据库中的特定表授权 grant 权限 on 数据库.* to 账户@主机名 对特定数据库中的所有表给与授权 grant 权限1,权限2,权限3 on *.* to 账户@主机名 对所有库中的所有表给与多个授权 grant all privileges on *.* to 账户@主机名 对所有库和所有表授权所有权限
退出数据库，使用root登录，开始权限设置
[root@master ~]# mysql -uroot -p
MariaDB [(none)]> use mysql;
MariaDB [(none)]> grant all privileges on . to [email protected];
MariaDB [mysql]> show grants for yuchao@127.0.0.1;
移除权限
MariaDB [(none)]> revoke all privileges on *.* from yuchao@127.0.0.1;
配置mysql
1.中文编码设置，编辑mysql配置文件/etc/my.cnf，下入以下内容
[mysqld] character-set-server=utf8 collation-server=utf8_general_ci log-error=/var/log/mysqld.log [client] default-character-set=utf8 [mysql] default-character-set=utf8
2.授权配置
远程连接设置哦设置所有库，所有表的所有权限，赋值权限给所有ip地址的root用户
mysql > grant all privileges on *.* to root@'%' identified by 'password';
#创建用户
mysql > create user 'username'@'%' identified by 'password';
#刷新权限
flush privileges;
数据库备份与恢复
mysqldump命令用于备份数据库数据
[root@master ~]# mysqldump -u root -p --all-databases > /tmp/db.dump
进入mariadb数据库，删除一个db
[root@master ~]# mysql -uroot -p
MariaDB [(none)]> drop database s11;
进行数据恢复，吧刚才重定向备份的数据库文件导入到mysql中
[root@master ~]# mysql -uroot -p < /tmp/db.dump
MYSQL主从复制
MySQL数据库的主从复制方案，是其自带的功能，并且主从复制并不是复制磁盘上的数据库文件，而是通过binlog日志复制到需要同步的从服务器上。
MySQL数据库支持单向、双向、链式级联，等不同业务场景的复制。在复制的过程中，一台服务器充当主服务器（Master），接收来自用户的内容更新，而一个或多个其他的服务器充当从服务器（slave），接收来自Master上binlog文件的日志内容，解析出SQL，重新更新到Slave，使得主从服务器数据达到一致。
主从复制的逻辑有以下几种
一主一从，单向主从同步模式，只能在Master端写入数据
一主多从
双主主复制逻辑架构，此架构可以在Master1或Master2进行数据写入，或者两端同事写入（特殊设置）
在生产环境中，MySQL主从复制都是异步的复制方式，即不是严格的实时复制，但是给用户的体验都是实时的。
MySQL主从复制集群功能使得MySQL数据库支持大规模高并发读写成为可能，且有效的保护了服务器宕机的数据备份。
应用场景
利用复制功能当Master服务器出现问题时，我们可以人工的切换到从服务器继续提供服务，此时服务器的数据和宕机时的数据几乎完全一致。
复制功能也可用作数据备份，但是如果人为的执行drop,delete等语句删除，那么从库的备份功能也就失效了.
主从机制实现原理
(1) master将改变记录到二进制日志(binary log)中（这些记录叫做二进制日志事件，binary log events）； (2) slave将master的binary log events拷贝到它的中继日志(relay log)； (3) slave重做中继日志中的事件，将改变反映它自己的数据。
master主库配置
#查看数据库状态
systemctl status mariadb
#停mariadb
systemctl stop mariadb
#修改配置文件
vim /etc/my.cnf
#修改内容
#解释：server-id服务的唯一标识（主从之间都必须不同）；log-bin启动二进制日志名称为mysql-bin
[mysqld]
server-id=1
log-bin=mysql-bin
#重启mariadb
systemctl start mariadb
master主库添加从库账号
1.新建用于主从同步的用户chaoge,允许登录的从库是'192.168.178.130' create user 'chaoge'@'192.168.178.130' identified by 'redhat';
2.#题外话：如果提示密码太简单不复合策略加在前面加这句
mysql> set global validate_password_policy=0;
3.给从库账号授权,说明给chaoge从库复制的权限，在192.168.178.130机器上复制
grant replication slave on . to ‘chaoge’@‘192.168.178.130’;
#检查主库创建的复制账号
select user,host from mysql.user;
#检查授权账号的权限
show grants for chaoge@‘192.168.178.130’;
实现对主数据库锁表只读，防止数据写入，数据复制失败
flush table with read lock;
4.检查主库的状态
MariaDB [(none)]> show master status
-> ;
+------------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000001 | 575 | | |
+------------------+----------+--------------+------------------+
1 row in set (0.00 sec)
File是二进制日志文件名，Position 是日志开始的位置。后面从库会用到 后面从库会用到 后面从库会用到！！！！！！
5.锁表后，一定要单独再打开一个SSH窗口，导出数据库的所有数据，
[root@oldboy_python ~ 19:32:45]#mysqldump -uroot -p --all-databases > /data/all.sql
6.确保数据导出后，没有数据插入，完毕再查看主库状态
show master status;
7.导出数据完毕后，解锁主库，恢复可写；
unlock tables;
8.将备份导出的数据scp至Slave数据库
scp /data/all.sql [email protected]:/data/
slave从库配置
1.设置server-id值并关闭binlog功能参数
数据库的server-id在主从复制体系内是唯一的，Slave的server-id要与主库和其他从库不同，并且注释掉Slave的binlog参数。
2.因此修改Slave的/etc/my.cnf，写入
[mysqld]
server-id=3
3.重启数据库
systemctl restart mariadb
4.检查Slava从数据库的各项参数
show variables like 'log_bin';
show variables like 'server_id';
5.恢复主库Master的数据导入到Slave库
导入数据（注意sql文件的路径）
mysql>source /data/all.sql;
方法二：
#mysql -uroot -p < abc.sql
6.配置复制的参数，Slave从库连接Master主库的配置
mysql > change master to master_host='192.168.178.129',
master_user='chaoge',
master_password='redhat',
master_log_file='mysql-bin.000001',
master_log_pos=575;
7.启动从库的同步开关，测试主从复制的情况
start slave;
8.查看复制状态
show slave status\G;
检查主从复制是否成功的关键在于
MariaDB [(none)]> show slave status\G *************************** 1. row *************************** Slave_IO_State: Waiting for master to send event Master_Host: 192.168.119.10 Master_User: chaoge Master_Port: 3306 Connect_Retry: 60 Master_Log_File: mysql-bin.000001 Read_Master_Log_Pos: 1039 Relay_Log_File: slave-relay-bin.000002 Relay_Log_Pos: 537 Relay_Master_Log_File: mysql-bin.000001 Slave_IO_Running: Yes Slave_SQL_Running: Yes
tip：
注意此处还未配置从库的只读模式，只需在slave服务器上配置/etc/my.cnf，加上以下配置，并且在slave上创建普通用户，使用普通用户主从同步即可达到只读的效果
如果用root用户，无法达到readonly，这是一个坑
[mysqld] character-set-server=utf8 collation-server=utf8_general_ci log-error=/var/log/mysqld.log server-id=3 read-only=true [client] default-character-set=utf8 [mysql] default-character-set=utf8
如果中间有
Slave_IO_Running: No
Slave_SQL_Running: Yes
如果是slave_io_running no了，那么就我个人看有三种情况，一个是网络有问题，连接不上，像有一次我用虚拟机搭建replication，使用了nat的网络结构，就是死都连不上，第二个是有可能my.cnf有问题，配置文件怎么写就不说了，网上太多了，最后一个是授权的问题，replication slave和file权限是必须的。如果不怕死就all咯。。
一旦io为no了先看err日志，看看爆什么错，很可能是网络，也有可能是包太大收不了，这个时候主备上改max_allowed_packet这个参数。
如果是slave_sql_running no了，那么也有两种可能，一种是slave机器上这个表中出现了其他的写操作，就是程序写了，这个是会有问题的，今天我想重现，但是有时候会有问题，有时候就没有问题，现在还不是太明了，后面再更新，还有一种占绝大多数可能的是slave进程重启，事务回滚造成的，这也是mysql的一种自我保护的措施，像关键时候只读一样。
这个时候想恢复的话，只要停掉slave，set GLOBAL SQL_SLAVE_SKIP_COUNTER=1;再开一下slave就可以了，这个全局变量赋值为N的意思是：
This statement skips the next N events from the master. This is useful for recovering from replication stops caused by a statement.
This statement is valid only when the slave thread is not running. Otherwise, it produces an error.
呵呵，讲的比我清楚。
MYSQL镜像服务器因错误停止的恢复
下午主服务器，由于一些原因，导致死机，重启后，发现从服务器的数据没有跟上。
配好MYSQL主从也才前几天的事，没多少经验，第一次碰上这问题，有点焦急。不过，自己试了下，还算解决了：）
从服务器上
Master_Log_File: mysqlhxmaster.000007
Read_Master_Log_Pos: 84285377
看一下主服务器：mysqlhxmaster.000007 | 84450528 |
已经过后很多了，确实没跟上。
show slave status\G
Slave_IO_Running: Yes
Slave_SQL_Running: No
有问题了，Slave_SQL_Running应该是Yes才对。
再往下看，有错误的提示：
Last_Errno: 1053
Last_Error: Query partially completed on the master (error on master: 1053) and was aborted. There is a chance that your master is inconsistent at this point. If you are sure that your master is ok, run this query manually on the slave and then restart the slave with SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; START SLAVE; . Query: ‘INSERT INTO hx_stat_record …(一句SQL语句)’
这里有说明要怎么操作了：）
先stop slave，然后执行了一下提示的语句，再SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; START SLAVE;
show slave status\G
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
OK了，从服务器也在几分钟内把堆积的log处理完了，两边又同步了：)
从MYSQL服务器Slave_IO_Running: No的解决2
早晨机房意外断电，导致了发现mysql从服务器同步异常。使用以前碰到的Slave_SQL_Running为No的解决办法无效，仍然无法同步。
查看一下状态show slave status
Master_Log_File: mysqlmaster.000079
Read_Master_Log_Pos: 183913228
Relay_Log_File: hx-relay-bin.002934
Relay_Log_Pos: 183913371
Relay_Master_Log_File: mysqlmaster.000079
Slave_IO_Running: No
Slave_SQL_Running: Yes
主服务器show master status\G
File: mysqlmaster.000080
Position: 13818288
Binlog_Do_DB:
Binlog_Ignore_DB: mysql,test
mysql错误日志：
100512 9:13:17 [Note] Slave SQL thread initialized, starting replication in log ‘mysqlmaster.000079’ at position 183913228, relay log ‘./hx-relay-bin.002934’ position: 183913371
100512 9:13:17 [Note] Slave I/O thread: connected to master ‘[email protected]:3306’, replication started in log ‘mysqlmaster.000079’ at position 183913228
100512 9:13:17 [ERROR] Error reading packet from server: Client requested master to start replication from impossible position ( server_errno=1236)
100512 9:13:17 [ERROR] Got fatal error 1236: ‘Client requested master to start replication from impossible position’ from master when reading data from binary log
100512 9:13:17 [Note] Slave I/O thread exiting, read up to log ‘mysqlmaster.000079’, position 183913228
这次是Slave_IO_Running为No，从日志上来看，服务器读mysqlmaster.000079这个Log的183913228这个位置时发生错误，这个位置不存在，于是无法同步。
查看一下这个Log的最后几行：
/!40019 SET @@session.max_insert_delayed_threads=0/;
/!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0/;
at 4
#100511 9:35:15 server id 1 end_log_pos 98 Start: binlog v 4, server v 5.0.27-standard-log created 100511 9:35:15
Warning: this binlog was not closed properly. Most probably mysqld crashed writing it.
尝试从损坏之前的位置开始
SLAVE STOP;
CHANGE MASTER TO MASTER_LOG_FILE=‘mysqlcncnmaster.000079’, MASTER_LOG_POS=183913220;
SLAVE START;
无效！
只好从新的日志开始
SLAVE STOP;
CHANGE MASTER TO MASTER_LOG_FILE=‘mysqlcncnmaster.000080’, MASTER_LOG_POS=0;
SLAVE START;
此时Slave_IO_Running恢复为Yes，同步进行了！观察了会儿，没有任何出错迹象，问题解决。
另外，出现Slave_IO_Running:NO还有一个原因是slave上没有权限读master上的数据。
或者
Slave_IO_Running: Yes
Slave_SQL_Running: No
进入slave服务器，运行：
mysql> show slave status\G
.......
Relay_Log_File: localhost-relay-bin.000535
Relay_Log_Pos: 21795072
Relay_Master_Log_File: localhost-bin.000094
Slave_IO_Running: Yes
Slave_SQL_Running: No
Replicate_Do_DB:
Replicate_Ignore_DB:
......
解决办法一、
Slave_SQL_Running: No
1.程序可能在slave上进行了写操作
2.也可能是slave机器重起后，事务回滚造成的.
一般是事务回滚造成的：
解决办法：
mysql> stop slave ;
mysql> set GLOBAL SQL_SLAVE_SKIP_COUNTER=1;
mysql> start slave ;
解决办法二、
首先停掉Slave服务：slave stop
到主服务器上查看主机状态：
记录File和Position对应的值
进入master
mysql> show master status;
±---------------------±---------±-------------±-----------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
±---------------------±---------±-------------±-----------------+
| localhost-bin.000094 | 33622483 | | |
±---------------------±---------±-------------±-----------------+
1 row in set (0.00 sec)
然后到slave服务器上执行手动同步：
mysql> change master to
master_host=‘master_ip’,
master_user=‘user’,
master_password=‘pwd’,
master_port=3306,
master_log_file=localhost-bin.000094’,
master_log_pos=33622483 ;
1 row in set (0.00 sec)
mysql> start slave ;
1 row in set (0.00 sec)
mysql> show slave status\G
*************************** 1. row ***************************
…
Master_Log_File: localhost-bin.000094
Read_Master_Log_Pos: 33768775
Relay_Log_File: localhost-relay-bin.000537
Relay_Log_Pos: 1094034
Relay_Master_Log_File: localhost-bin.000094
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
手动同步需要停止master的写操作！