binlog

本文内容主要来源：官方文档中文版第6章“ MySQL中的复制 ”。本文只记录配置要点。 1. 主数据库配置（通常在 /etc/my.cnf ）： 在 [mysqld] 中加入以下几条配置： server-id=1（为任意值） log-bin=mysql-bin binlog_do_db=你要复制的数据库（实际上是要做 二进制日志 的数据库） binlog_ignore_db=mysql（要忽略的数据库） 重启MySQL服务器后进入client，创建数据库用户以便“从数据库”连接： GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%.mydomain.com' IDENTIFIED BY 'slavepass'; （用户名、密码以及从服务器主机地址可自定义） 然后刷新读写缓冲区并锁定表读写操作： FLUSH TABLES WITH READ LOCK; 这个时候再另外连接到主机shell（不要关闭当前MySQL连接，否则锁定会解除），开始复制数据库到从数据库（事先要创建同名数据库，也可以使用“ mysqladmin -h 从服务器地址 create 数据库名 ”进行创建）： mysqldump --opt 要复制的数据库 -p主数据库root密码 -R -B | mysql -h从服务器地址 要复制的数据库名 -p从数据库root密码 复制完后

Binlog是mysql的二进制日志， 它的主要目的是 基于数据重放机制 最大可能的 恢复数据库的更新 ，因为二进制日志包含 数据库备份后进行的所有更新 。 Mysql的 主从复制 特性也依赖于此实现。 Binlog的启动只增加 1% 的mysql负载 ， 所以不会成为瓶颈。 Mysql在数据操作成功后将按照逐LOG_EVENT递增的形式追加一条binlog。 Binlog配置启用， vim my.cnf log_bin = /var/log/mysql-bin.log ## 可选配置 binlog_format = MIXED #默认statement， 推荐mixed expire_logs_days = 7 max_binlog_size = 100m Binlog三种格式： 1 基于语句 statement 记录数据变化的sql语句。一般日志量较小，但是语句执行的可靠性较低。 2 基于行 row 记录被修改的数据行。数据细节清晰可靠，但一般日志量较大。 3 混合模式mixed 以上两种格式的合并。 Binlog查看： binlog文件由 索引文件 及 具体日志 文件构成： mysql-bin.index #索引文件， 内容为所有日志文件名， 一行一个 mysql-bin.000001 #具体日志文件， 每次mysql服务重启都会新增一个日志文件， 序列号增一。

I'm running a master-slave MySQL binary log replication system (phew!) that, for some data, is not in sync (meaning, the master holds more data than the slave). But the slave stops very frequently on the slightest MySQL error, can this be disabled? (perhaps a my.cnf setting for the replicating slave ignore-replicating-errors or some of the sort ;) ) This is what happens, every now and then, when the slave tries to replicate an item that does not exist, the slave just dies. a quick check at SHOW SLAVE STATUS \G; gives Slave-IO-Running: Yes Slave-SQL-Running: No Replicate-Do-DB: Last-Errno: 1062

MySQL 5.5 中对于二进制日志 (binlog) 有 3 种不同的格式可选： Mixed,Statement,Row ，默认格式是 Statement 。总结一下这三种格式日志的优缺点。 MySQL Replication 复制可以是基于一条语句 (Statement Level) ，也可以是基于一条记录 (Row Level) ，可以在 MySQL 的配置参数中设定这个复制级别，不同复制级别的设置会影响到 Master 端的 bin-log 日志格式。 1. Row 日志中会记录成每一行数据被修改的形式，然后在 slave 端再对相同的数据进行修改。 优点 ：在 row 模式下， bin-log 中可以不记录执行的 SQL 语句的上下文相关的信息，仅仅只需要记录那一条记录被修改了，修改成什么样了。所以 row 的日志内容会非常清楚的记录下每一行数据修改的细节，非常容易理解。而且不会出现某些特定情况下的存储过程或 function ，以及 trigger 的调用和触发无法被正确复制的问题。 缺点 ：在 row 模式下，所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容，比如有这样一条 update 语句： 1 UPDATE product SET owner_member_id = 'b' WHERE owner_member_id