主+备库（备库设置readonly对超级 (super) 权限用户是无效的，而用于同步更新的线程，就拥有超级权限）
binlog 有两种格式，一种是 statement（SQL 语句的原文，delete 带 limit，很可能会出现主备数据不一致的情况），一种是 row（每一行数据修改的细节）,mixed(mysql自己判断用哪种)
主库接收到客户端的更新请求后，执行内部事务的更新逻辑，同时写 binlog，备库跟主库之间维持了一个长连接，备库请求binlog，主库本地读取 binlog发给备库，备库接收binlog写到本地文件，称为中转日志（relay log），备库sql_thread 读取中转日志，解析出日志里的命令，并执行
seconds_behind_master 备库落后主库的日志差值确定是否需要介入处理，可靠性优先-切换停机，可用性优先-可能出现不一致
一主多从。除了备库外，可以多接几个从库，让这些从库来分担读的压力。
通过 binlog 输出到外部系统，比如 Hadoop 这类系统，让外部系统提供统计类查询的能力。
不要一次性地用 delete 语句删除太多数据，防止主备延迟增大
使用 row 格式的 binlog 时，数据不一致的问题更容易被发现。而使用 mixed 或者 statement 格式的 binlog 时，数据很可能悄悄地就不一致了
MySQL 高可用系统的可用性，是依赖于主备延迟的。延迟的时间越小，在主库故障的时候，服务恢复需要的时间就越短，可用性就越高
官方的 5.6 版本之前，MySQL 只支持单线程sql_thread复制，由此在主库并发高、TPS 高时就会出现严重的主备延迟问题
后续版本将sql_thread变为协调器读取中转日志和分发事务。真正更新日志的，变成了 worker 线程，分发策略按库/按表/按行，考虑一致性和事务