复制解决的基本问题
让一台服务器的数据让其他服务器保持同步，一台主库的数据可以同步到多台备库上，悲苦本身也可以被配置成另外一台服务器的主库。
MySQL支持两种复制方式：基于行的复制和基于语句的复制（逻辑复制）。这两种都是在主库上记录二进制日志，在备库重放日志的方式来实现异步的数据复制，这说明同一时间主备库存在不一致，并且无法保证主备之间的延迟。
常见的复制用途
数据分布：MySQL通常复制不会造成很大的贷款压力，但基于行的复制会比基于语句的复制带宽压力大，可以随意停止或开始复制，并在不同的地理位置来分布数据备份，例如不同的数据中心，即使在不稳定的网络环境下，远程复制也可以工作，单位了低复制延迟，最好有一个稳定的低延迟连接。
负载均衡：将读操作分布到多个服务器上，实现对读密集型应用的优化
备份：对备份来说，复制是一项很有意义的技术补充，但复制既不是备份也不能取代备份。
高可用性和故障切换：帮助应用程序避免MySQL单点失败，一个包含复制的设计良好的故障切换系统能够显著地缩短宕机时间
MySQL升级测试：使用一个更高版本的MySQL作为备库，保证在升级全部实例之前。查询能够在备库按照预期执行。
复制步骤
主库把数据更改记录到二进制日志中
在提交失误完成数据更新前，主库将数据更新的时间记录到二进制日志中，按照事务提交的顺序而非每条语句的执行顺序来记录二进制日志，在记录之后，主库会告诉存储引擎可以提交事物了。
备库将主库上的日志复制到自己的中继日志中
备库读取中继日志中的时间，将其重放到备库数据之上
基于语句的复制
主库会记录那些造成数据更改的查询，当悲苦读取并重放这些事件时，实际上这只是把主库上执行过的SQL在执行一遍
优势：实现简单，二进制日志里面的时间更加紧凑，不会使用太多带宽
劣势：更新必须串行，需要更多的锁，不是所有的引擎都支持这种复制模式，存在一些无法被正确复制的SQL，存储过程和触发器在使用基于语句的复制模式时也可能存在问题
基于行的复制
将实际数据记录在二进制日志中，可以正确复制每一行，一些语句可以被更有效的复制
一主多备结构
为不同的角色使用不同的备库比如添加不同的所以或使用不同的存储引擎
把一台备库当做代用的主库，除了复制没有其他数据传输
将一台备库放到远程数据中心，用作灾难恢复
延迟一个或多个备库，以备灾难恢复
使用一个备库作为备份、培训、开发、或者测试使用服务器
主-被动模式服务器对称设置
确保两台服务器上有相同的数据
启用二进制日志，选择唯一的服务器ID，并创建复制账号
启用备库更新的日志记录
把被动服务器配置成只读，防止可能与主动服务器上的更新产生冲突
启动每个服务器的MySQL实例
将每个主库设置为对方的备库，使用新建的二进制日志开始工作
主动服务器上更新时：更新记录到二进制日志中，通过复制传递给被动服务器的中继日志中被动服务器执行查询并将其记录到自己的二进制日志中，由于事件的服务器ID与主动服务器的相同，因此主动服务器忽略这些事件。
这种类似于创建一个热备份，但是可以使用这个备份来提高性能，比如执行读操作、备份、离线维护升级等。但是不会获得比单台服务器更好的写性能。
拥有备库的主-主结构
为每一个主库增加一个备库，增加了冗余，对于不同地理位置的复制拓扑，能够消除站点但电视系哦啊的问题可以将读查询分配到备库上
主库失效时，用备库来代替主库是可行的，也可以把备库只想一个不同的主库，但需要考虑增加的复杂度
环形复制拓扑
每一个服务器都是他之前服务器的备库，是他之后服务器的主库
主库分发主库备库
分发主库实际上也是一个备库，他的目的是提取和提供主库的二进制日志多个备库连接到分发主库，原来的主库摆脱了负担，为了避免在分发主库上做实际的查询，可以将他的表修改为blackhole存储引擎
可以使用分发主库实现对二进制日志时间执行过滤和重写规则，这个比在每个备库上重复进行日志记录、重写和过滤效率高得多
在分发主库上使用blackhole表，可以支持更多的备库，虽然会在分发主库上执行查询，但其代价非常小，因为blackhole的表里面没有任何数据，blackhole表的缺点是存在bug，在某些情况下会忘记将自增的id写入二进制日志
使用分发主库无法使用一个备库来代替主库，因为分发主库的存在，导致各个备库与原始主库的二进制日志坐标已经不相同
日志服务器
mysqlbinlog：用来记录mysql内部增删改查等对数据库有更新的内容的记录，对数据库的查询select或show等不会被binlog记录，主要用于数据库的主从复制以及增量恢复
复制作为应用二进制日志的方法已经被大量的用户所测试，能够证明是可行的的，mysqlbinlog可能无法正确生成二进制日志中的数据更新
复制的速度更快，因为无需将语句从日志导出来并传送给mysql
很容易观察到复制过程
方便处理错误，例如可以跳过执行失败的语句
方便过滤复制事件
有时候mysqlbinlog会因为日志记录格式更改无法读取二进制日志
缓存
应用层以下的缓存：MySQL服务器有自己的内部缓存，也可以构建自己的缓存和汇总表，缓存表比许多应用层缓存更加持久，在服务器重启之后他们还存在
应用层缓存：在同一台机器的内存中缓存数据，或者通过网络存在另一台机器的内存中，应用层缓存可以节省获取数据以及基于这些数据进行计算。但是缓存命中率低，并且可能使用更多的内存。
应用缓存之本地缓存：小，只在进程处理请求期间存在于进程内存中。可以避免对某些资源的重复请求
应用缓存之本地共享内存缓存：中等大小，快速，难以在多台机器间同步，对小型的半静态位数据比较合适，但是访问非常快，通常比任何远程缓存访问都快
应用缓存之分布式内存缓存：比本地共享内存缓存大得多，增长容易，缓存中创建的数据的每一个比特都只有一个副本，不会浪费内存，也不会因为缓存创建的数据存在不同的地方而引入一致性问题。非常适合存储共享对象，但是演示高，最有效的方法是批量进行多个获取操作，还要考虑怎么增加更多的节点，以及某个节点崩溃了怎么处理，应用程序必须决定在节点间怎么分布或充分不缓存对象
应用缓存之磁盘缓存：最好是持久性对象，很难全部存进内存的对象或者金泰内容
缓存控制策略
问题：重复数据，有多而地方需要更新数据，所以要避免督导脏数据
TTL（timetolive存活时间）：缓存对象存储是设置一个过期时间，可以通过清理进程在未达到过期时间后删除对象，或者留到下次访问时再清理，对于数据很少变更或没有新数据的情况，这是最好的失效策略。
显示失效：如果不能接受脏数据，那么在更新原始数据时同时使缓存失效
写——失效：标记缓存数据已经过期（是否清理缓存数据是可选的）。
写——更新：更新数据时替换掉缓存项
读时失效：采用对象版本控制
缓存对象分层：分层缓存对象对检索、失效和内存利用都有帮助，相对于只缓存对象，也可以缓存对象的ID、对象的ID组等需要一起检索的数据
预生成内容：在后台预先请求一些页面，并将结果存为静态页面。
作为基础组件的缓存
使用handlerSocket和memcached：handlerSocketto刚刚一个简单的协议访问innodbhandler绕过上层的服务器层，通过网络直接连接innodb引擎，通过memcached协议访问innoDB
文章转自：