不停库不锁表在线主从配置mysql
1，Mysqldump对于10G如下的数据库或表，比较适用又快捷。当数据量达到100-500G的时候，mysql就力不从心了。ios
2，Percona-xtrabackup能够实现mysql在线热备工做。可进行全量，增量，单表备份和还原。sql
3，2.2版本的xtrabackup能对innoDB和XtraDB存储引擎的数据库非阻塞的备份，对myISAM的备份经过加表读锁的方式实现，2.3版本xtrabackup命令直接支持myISAM引擎。数据库
Xtrabakup 优点：1，无需中止数据库进行InnoDB热备安全
2，增量备份MySQL服务器
3， 热压缩到传输到其余服务器app
4， 能比较容易的建立主从同步异步
5， 备份MySQL时不会增大服务器负载。性能
4，主从复制是为了实现读写分离，减轻主库负载，还能够数据备份，保证数据恢复，还能够主从切换高可用。ui
5，复制类型
· 基于语句的复制：STATEMENT 在主服务器执行的SQL语句，在从上执行一样的语句，有可能因为执行上下文环境不一样而致使数据不一致。（mysql在5.7.7之前默认采用STATEENT,在5.7.7及之后版本，默认改用row-based
· 基于行的复制：row ，把改变的内容复制过去，不是把命令在从上执行一遍。从mysql5.0开始支持，可以严格保证数据完整一致。（注：迁移时，从库改正了字段默认值定义，但数据在主库更改后，即便产生的新数据默认值正确。但基于行的复制依然用不正确的值字段所有更新）
· 混合类型的复制：MIXED ，默认采用基于语句的复制，一旦发现基于语句的没法精确复制时，就会采用基于行的复制。
- 1 mysql 系统库mysql库里面的表的日志记录格式，在经过如INSERT,UPDATE、DELETE、TRUNCATE等方式直接修改数据的语句，使用binlog_format指定的方式记录，但使用GRANT、ALTER、CREATE、RENAME等改动的mysql库里数据的，会强制使用statement-based方式记录binlog。
在线修改二进制日志，须要SUPER权限（如SET SESSION binlog_format=MIXED）
6.2 复制类型分为异步复制和半同步复制。
异步复制：一般没后，说明指的都是异步。在主库执行完Commit后，在主库写入binlog日志后便可成功返回客户端，不等binlog日志传送给从库，一旦主库宕机，可能会丢失日志。
半同步复制；是等其中一个从库也接收到binlog事物并成功写入relay log以后，才返回commit操做成功给客户端。这样保证事务成功提交后至少有两份日志，一份在主库binlog上，另外一份在从库relay log上。进一步保证数据完整性。
原理
(1) master将改变记录到二进制日志(binary log)中（这些记录叫作二进制日志事件，binary log events）；
(2) slave将master的binary log events拷贝到它的中继日志(relay log)；
(3) slave重作中继日志中的事件，将改变反映它本身的数据。
7，配置主从
1，准备工做；主从版本一致—>主库受权复制账号—>确保开启binlog及主从server_id惟一—>xtrabackup恢复到从库—>记录xtrabackup_binlog_info中binlog名称及偏移量—>从库change master to —>slave start—>检查两个yes
,2， 主库上建立复制帐号
mysql> GRANT REPLICATION SLAVE ON *.* TO 'slave_ali'@'192.168.5.%' IDENTIFIED BY 'slave_ali_pass';
mysql> FLUSH PRIVILEGES;
3，使用percona-Xtrabackup恢复数据。
假设，全量备份，全量恢复，不涉及增量。
mysql> CREATE USER 'bkpuser'@'localhost' IDENTIFIED BY 'bkppass';
mysql> GRANT RELOAD, LOCK TABLES, REPLICATION CLIENT,PROCESS,SUPER ON *.* TO 'bkpuser'@'localhost';
mysql> FLUSH PRIVILEGES;
假设 MySQL 安装目录在/opt/mysql，my.cnf配置文件/opt/mysql/my.cnf，端口3306，数据目录/opt/mysql_data，sock位于/opt/mysql_data/mysql.sock。备份数据放在/data/backup/mysql/。
3.1全量备份（默认会以当天 日期+时间 戳命名备份目录，如 2015-09-16_00-00-02)
$ export BKP_PASS="bkppass"
$ innobackupex --defaults-file=/opt/mysql/my.cnf --host=localhost --port=3306 --user=bkpuser --password=${BKP_PASS} /data/backup/mysql
3.2 全量恢复(在恢复的数据库服务器（从库）上)
恢复准备
$ innobackupex --use-memory=16G --apply-log 2015-09-16_00-00-02
确认数据库是关闭的，而且datadir，目录下为空
$ innobackupex --defaults-file=/opt/mysql/my.cnf --use-memory=16G --copy-back 2015-09-16_00-00-02
第一步是恢复准备，apply-log应用全备时 log sequence number 以后的数据，完了后会输出相似 InnoDB: Last MySQL binlog file position 0 262484673, file name ./mysql-bin.000135 的信息，告诉咱们了后面的从库应该从哪一个地方开始复制。时间不会很长，但最好用screen之类的软件放到后台执行，以避免终端断开，功亏一篑。
第二步使用新的my.cnf文件，将完整的mysql数据文件拷贝到datadir下。
- 作从库
上面恢复过程最后一步apply-log完成以后，会获得一个lsn position 和binlog文件名：26248467三、mysql-bin.000135。下面开始从库制做。
通常在copy-back以后须要修改数据文件目录的属性：
# chown -R mysql.mysql /opt/mysql_data
4.1 my.cnf
从库的配置文件简单一点能够从主库拷贝过来。根据须要要注意如下几处。
1，server-id必定不能与主库相同，不然，会出现以下错误：Slave: received end packet FROM server, apparent master shutdown
2，从库通常做为只读库使用，因此为安全起见，设置只读 set global read_only=1;能够在从服务器的 my.cnf 里加入read-only参数来实现这一点，惟一须要注意的一点事read-only仅对没有super权限的用户有效。因此最好核对一下链接从服务器的用户，确保其没有super权限。
3，关于从库的事件
MYSQL Replication 能够很好的达到你的预期：从库的事件不会本身去执行，主库会把event执行的结果直接同步。在statement模式下，复制的是 event BODY 里的SQL，在row模式下是主库事件执行完成后影响的行精确复制。
4，从库 event_scheduler 参数是被忽略的，而且每一个event 状态会是 SLAVESIDE_DISABLED ，但CREATE/ALTER EVENT等操做语句是会复制。主从切换后，从库事件状态会变成ENABLE。
5，参数调整
从库是不容许写入的，不然数据就不一致了。从库实例的配置能够不要主库那么高，好比原16G的buffer pool，根据用途，从库能够设到4-8G（当时前提是未来你也不打算把它切换为主库用）。相应的，read_buffer_size，sort_buffer_size, query_cache_size 这些读相关参数能够略微增大。
6，skip-slave-start
主从建立完成后，默认状况下次启动从库，会自动启动复制进程，通常这也正是咱们须要的，但在维护阶段时你可能不想从库启动后当即开始复制，--skip-slave-start选项能够帮到你。
7，log-slave-updates
正常状况从库是不须要写回放日志产生的binlog，无形中增长服务器压力。但若是你想要实现级联复制即 A -> B -> C ，B同时是A的从库，也是C的主库，就须要开启 log-bin 和 log-slave-updates 。
另外，建议显示设置 log-bin=mysql-bin 确保主从正常切换。 show variables like 'log%' 查看当前值。
8，关于过滤表见mysql-replica-filter
9，sync_binlog
For the greatest possible durability and consistency in a replication setup using InnoDB with transactions, you should use innodb_flush_log_at_trx_commit=1 and sync_binlog=1 in the master my.cnf file.
上面的话同时也意味着性能最低。能够在这埋点，假如出现慢的状况，把两参数调成2。
4.2 启动从库
# /opt/mysql/bin/mysqld_safe --defaults-file=/opt/mysql/my.cnf &
提示：若是你不肯定这个库是谁的从库，保守起见加上--skip-slave-start启动，兴许能防止数据不一致。
4.3 change master（从库上）
$ mysql -uslave_ali -p'slave_ali_pass' -S /opt/mysql_data/mysql.sock
mysql> change master to master_host=MASTER_HOST, master_port=3306,
master_user='slave_ali',master_password='slave_ali_pass',
master_log_file='mysql-bin.000135', master_log_pos=262484673;
mysql> show slave status\G
mysql> start slave;
mysql> show slave status\G
4.4 验证同步延迟
从库执行 show slave status\G
Slave_IO_State: Waiting for master to send event
Master_Log_File: mysql-bin.000004
Read_Master_Log_Pos: 931
Relay_Log_File: slave1-relay-bin.000056
Relay_Log_Pos: 950
Relay_Master_Log_File: mysql-bin.000004
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Exec_Master_Log_Pos: 931
Relay_Log_Space: 408
Seconds_Behind_Master: 0
Master_Log_File： I/O线程当前正在读取的主服务器二进制日志文件的名称
Read_Master_Log_Pos：本机I/O线程读取主服务器二进制日志位置
上面2各值，与在主库执行show master status;看到的值若是基本接近，说明从库IO线程已经遇上了主库的binlog。
Relay_Master_Log_File: 由SQL线程执行的包含多数近期事件的主服务器二进制日志文件的名称
Exec_Master_Log_Pos: SQL线程执行来自master的二进制日志最后一个事件位置
与上面的Relay_Master_Log_File一块儿，同Master_Log_File、Read_Master_Log_Pos比较，能看到SQL线程是否已经遇上从库本地的IO线程。
Slave_IO_Running：I/O线程是否启动并成功链接到主服务器上
通常和下面的Slave_IO_Running和Seconds_Behind_Master一块儿监控主从健康状态
Slave_SQL_Running：SQL线程是否启动
Seconds_Behind_Master: 从属服务器“落后”多少秒
Mysql主从不一样步解决方法
主从同步配置好后，运行一段时间，出现了不一样步现象，
能够用命令检查，
msyq > show slave status \G;
Last_Errno: 1062
Last_Error: Error 'Duplicate entry '149' for key 'PRIMARY'' on query. Default database: 'zabbix'. Query: 'insert into escalations (escalationid,actionid,status,triggerid,itemid,eventid,r_eventid) values (149,7,0,16272,null,3334811,null)'
看报错，应该是主MYSQL上建表时，主键有重复的值报错，形成从不能同步。
解决的办法是在从库上执行:
mysql> slave stop;
mysql> set GLOBAL SQL_SLAVE_SKIP_COUNTER=1;
mysql> slave start;
上面的方法能够解决问题，还有一种解决问题的办法是经过修改mysql的配置文件，让从库的同步线程忽略这个错误，
修改mysql配置文件 /etc/my.cnf 在 [mysqld]下加一行slave_skip_errors = 1062 ,保存重启mysql
mysql slave能够正常同步了.
MYSQL主从同步故障一例及解决过程！
nagios 报警，mysql_AB error，检查从库
show slave status \G; 果真
Slave_IO_Running: Yes
Slave_SQL_Running: No
并且出现了1062错误，还提示
Last_SQL_Error: Error 'Duplicate entry '1001-164761-0' for key 'PRIMARY'' on query. Default database: 'bug'. Query: 'insert into misdata (uid,mid,pid,state,mtime) values (164761,1001,0,-1,1262623560)'
tail -f mysql_error.log 查看错误日志
[ERROR] Slave SQL: Error 'Duplicate entry '1007-443786-0' for key 'PRIMARY'' on query. Default database: 'ufo'. Query: 'insert into misdata (uid,mid,pid,sta
te,mtime) values (443786,1007,0,-1,1262598003)', Error_code: 1062
100104 17:39:05 [Warning] Slave: Duplicate entry '1007-443786-0' for key 'PRIMARY' Error_code: 1062
100104 17:39:05 [ERROR] Error running query, slave SQL thread aborted. Fix the problem, and restart the slave SQL thread with "SLAVE START". We stopped at log 'ufolog.000058
8' position 55793296
解决思路：先中止同步，锁表，在从上从新配置
先手动同步一下，从库上首先 stop slave;中止同步
进入主库锁表，FLUSH TABLES WITH READ LOCK；
mysql> show master status;
进入从库，从新配置
mysql>change master to master_host='192.168.1.141', master_user='slave',
master_password='xxx',
master_port=3306,
master_log_file='ufo.000063',
master_log_pos=159164526;
完成后start slave;
回到主库
unlock tables; 解锁
回到从库 查看
show slave status \G
解决未果，尝试跳过错误的方法。
stop slave;
set global sql_slave_skip_counter=1; （1是指跳过一个错误）
slave start;
再show slave status \G;查看
结果仍是报错，由原来的164761变成其余数字。
/etc/my.cnf 修改从库的配置文件，在[mysqld]加入一行。
slave-skip-errors = 1062
mysql /etc/init.d/mysqld restart 重启下从库的
show slave status \G; 查看正常，这是数据可能已经不一样步了。
tail -f mysql_error.log 再次查看错误日志
100106 16:54:21 [Warning] Statement may not be safe to log in statement format. Statement: delete from `system_message_1` where `to_uid` = 181464 ORDER BY `id` ASC LIMIT 1 （大概意思是statement格式不安全）
statement format 应该是 binlog的一种格式，进入从库查看一下
show global variables like 'binlog_format';
果真当前的格式为statement
我须要把格式改成 mixed格式
修改从库的 my.cfg
在[mysqld]下面加入下面这行
binlog_format=mixed