侧重，主从复制，mysql客户端与服务端交互。
一.客户端查询服务整体流程
客户端查询 -> 查询缓存 -> sql解析器 -> 查询优化器 -> 执行引擎
客户端与服务端通信采用半双工形式。
不要查询大量数据，因为采用request-response模式，服务端必须转输完所有当前语句要求的数据才能停止。
二.主从复制
从库两个线程：io线程，sql线程。
从库与主库建立长连接，从库拉取binglog到一个从库的relay log中。
sql线程从relay log做sql重做。
当从库的binlog的进度追赶上主库的binlog则io线程阻塞，直到主库有通知从库。
从库io线程也会有流控，根据relay log的大小，假设是16M，则当relay log占用大小等于X时需要阻塞io线程。
等到从库sql线程消费relay log缓存中的log指令时才唤醒从库io线程。
但如果启用这个流控开关，带来的问题是主库挂了，并且磁盘损坏则会使数据大量在从库丢失。
复制两种模式：
基于语句：缺点是更新语句会有大量锁，以及有些语句需要用到数据库服务当前时间
基于行：就是将对应语名变成数据
优点：对于一些sql会更块，因为只是复制数据，但如果存在：update t1 set name='a';这样的语句，则会导致binlog要记录的日志数据比较大，时间会耗在网络传输上。但个人认为这种语句在类似互联网对接用户这块业务比较少，因此基于行复制比较合适。
缺点：查问题难，不知道执行了哪些语句。无法处理同步到从库的表schema修改。
主从布署结构：
可以是一个主，对应这个主有一个从，对应这个从又可以布署对应的从。这样多级布署，好处是数据冗余多份并且减轻主库的同步binlog压力。
将一个从库提升为另一个从库的主库binlog复制源，需要在这个从库配置：log_slave_updates
物理布署结构：
1.主/从
2.主（可读写）/主（可读写）
比较危险，避免不了对相同数据的写操作时，无法确定以哪一台数据库服务器为主。
3.主(可读写)/主(可读)
与主/从结构的唯一优点是，配置主（可读写），与主（可读）完全相同，在出现故障后恢复较快不需要重启即可提升对应主（可读）为主（可读写）。
扩容：
扩容需要考虑主/从的扩容。
一般如果从库用于读，业务场景数据：
40%写，60%读。
每台服务器读处理最大qps为：1000。
假设当前服务负载增加到原来两倍，则需要多少从库。
目前是一主，一从。基本负载能够跑满。
设原先qps为1000，则增加到两倍负载为2000。
也就是说，两倍负载后，需要处理800写，1200读。
由于从库还需要处理800的写，因此每台从库处理读请求仅为：200。
那么要处理1200读则需要至少6台。
具体配置需要：
主库能够允许相应从库replication slave权限。
CREATE
USER
'repl'
@
'%.mydomain.com'
IDENTIFIED
BY
'slavepass'
;
GRANT
REPLICATION
SLAVE
ON
*
.
*
TO
'repl'
@
'%.mydomain.com'
;