高性能MySQL复制与缓存

  1. 复制解决的基本问题

    让一台服务器的数据让其他服务器保持同步,一台主库的数据可以同步到多台备库上, 备库本身也可以被配置成另外一台服务器的主库。

    MySQL支持两种复制方式:基于行的复制和基于语句的复制(逻辑复制)。这两种都是在主库上记录二进制日志,在备库重放日志的方式来实现异步的数据复制, 这说明同一时间主备库存在不一致,并且无法保证主备之间的延迟。

  2. 常见的复制用途

    数据分布:MySQL通常复制不会造成很大的带宽压力,但基于行的复制会比基于语句的复制带宽压力大, 可以随意停止或开始复制,并在不同的地理位置来分布数据备份,例如不同的数据中心, 即使在不稳定的网络环境下,远程复制也可以工作,降低了单位复制延迟,最好有一个稳定的低延迟连接。

    负载均衡:将读操作分布到多个服务器上,实现对读密集型应用的优化

    备份:对备份来说,复制是一项很有意义的技术补充,但复制既不是备份也不能取代备份。

    高可用性和故障切换:帮助应用程序避免MySQL单点失败,一个包含复制的设计良好的故障切换系统能够显著地缩短宕机时间

    MySQL升级测试:使用一个更高版本的MySQL作为备库,保证在升级全部实例之前。查询能够在备库按照预期执行。

  3. 复制步骤

    主库把数据更改记录到二进制日志中

    在提交事物完成数据更新前,主库将数据更新的时间记录到二进制日志中,按照事务提交的顺序 而非每条语句的执行顺序来记录二进制日志,在记录之后,主库会告诉存储引擎可以提交事物了。

    备库将主库上的日志复制到自己的中继日志中

    备库读取中继日志中的时间,将其重放到备库数据之上

  4. 基于语句的复制

    主库会记录那些造成数据更改的查询,当备库读取并重放这些事件时,实际上这只是把主库上执行过的SQL在执行一遍

    优势:实现简单,二进制日志里面的时间更加紧凑,不会使用太多带宽

    劣势:更新必须串行,需要更多的锁,不是所有的引擎都支持这种复制模式,存在一些无法被正确复制的SQL, 存储过程和触发器在使用基于语句的复制模式时也可能存在问题

    基于行的复制

    将实际数据记录在二进制日志中,可以正确复制每一行,一些语句可以被更有效的复制

  5. 一主多备结构

    为不同的角色使用不同的备库比如 添加不同的索引或使用不同的存储引擎

    把一台备库当做代用的主库,除了复制没有其他数据传输

    将一台备库放到远程数据中心,用作灾难恢复

    延迟一个或多个备库,以备灾难恢复

    使用一个备库作为备份、培训、开发、或者测试使用服务器

  6. 主-被动模式服务器对称设置

    确保两台服务器上有相同的数据

    启用二进制日志,选择唯一的服务器ID,并创建复制账号

    启用备库更新的日志记录

    把被动服务器配置成只读,防止可能与主动服务器上的更新产生冲突

    启动每个服务器的MySQL实例

    将每个主库设置为对方的备库,使用新建的二进制日志开始工作

    主动服务器上更新时:更新记录到二进制日志中,通过复制传递给被动服务器的中继日志中 被动服务器执行查询并将其记录到自己的二进制日志中,由于事件的服务器ID与主动服务器的 相同,因此主动服务器忽略这些事件。

    这种类似于创建一个热备份,但是可以使用这个备份来提高性能,比如执行读操作、备份、离线 维护升级等。但是不会获得比单台服务器更好的写性能。

  7. 拥有备库的主-主结构

    为每一个主库增加一个备库,增加了冗余,对于不同地理位置的复制拓扑,能够消除站点断电失效的问题 可以将读查询分配到备库上

    主库失效时,用备库来代替主库是可行的,也可以把备库指向一个不同的主库,但需要考虑增加的复杂度

  8. 环形复制拓扑

    每一个服务器都是他之前服务器的备库,是他之后服务器的主库

  9. 主库 分发主库 备库

    分发主库实际上也是一个备库,他的目的是提取和提供主库的二进制日志 多个备库连接到分发主库,原来的主库摆脱了负担,为了避免在分发主库上做实际的查询, 可以将他的表修改为blackhole存储引擎

    可以使用分发主库实现对二进制日志时间执行过滤和重写规则,这个比在每个备库上重复进行日志记录、 重写和过滤效率高得多

    在分发主库上使用blackhole表,可以支持更多的备库,虽然会在分发主库上执行查询, 但其代价非常小,因为blackhole的表里面没有任何数据,blackhole表的缺点是存在bug, 在某些情况下会忘记将自增的id写入二进制日志

    使用分发主库无法使用一个备库来代替主库,因为分发主库的存在,导致各个备库与原始主库的二进制日志坐标已经不相同

  10. 日志服务器

    mysqlbinlog:用来记录mysql内部增删改查等对数据库有更新的内容的记录,对数据库的查询select或show等不会被binlog记录,主要用于数据库的主从复制以及增量恢复

    复制作为应用二进制日志的方法已经被大量的用户所测试,能够证明是可行的的,mysqlbinlog可能无法正确生成二进制日志中的数据更新

    复制的速度更快,因为无需将语句从日志导出来并传送给mysql

    很容易观察到复制过程

    方便处理错误,例如可以跳过执行失败的语句

    方便过滤复制事件

    有时候mysqlbinlog会因为日志记录格式更改无法读取二进制日志

  11. 缓存

    应用层以下的缓存:MySQL服务器有自己的内部缓存,也可以构建自己的缓存和汇总表,缓存表比许多应用层缓存更加持久,在服务器重启之后他们还存在

    应用层缓存:在同一台机器的内存中缓存数据,或者通过网络存在另一台机器的内存中, 应用层缓存可以节省获取数据以及基于这些数据进行计算。但是缓存命中率低,并且可能使用更多的内存。

    应用缓存之本地缓存:小,只在进程处理请求期间存在于进程内存中。可以避免对某些资源的重复请求

    应用缓存之本地共享内存缓存:中等大小,快速,难以在多台机器间同步,对小型的半静态位数据比较合适 ,但是访问非常快,通常比任何远程缓存访问都快

    应用缓存之分布式内存缓存:比本地共享内存缓存大得多,增长容易,缓存中创建的数据的每一个比特都只有一个副本, 不会浪费内存,也不会因为缓存创建的数据存在不同的地方而引入一致性问题。 非常适合存储共享对象,但是延时高,最有效的方法是批量进行多个获取操作,还要考虑怎么增加更多的节点, 以及某个节点崩溃了怎么处理,应用程序必须决定在节点间怎么分布或充分不缓存对象

    应用缓存之磁盘缓存:最好是持久性对象,很难全部存进内存的对象或者静态内容

  12. 缓存控制策略

    问题:重复数据,有多个地方需要更新数据,所以要避免读到脏数据

    TTL(time to live 存活时间):缓存对象存储是设置一个过期时间,可以通过清理进程在未达到过期时间后删除对象, 或者留到下次访问时再清理,对于数据很少变更或没有新数据的情况,这是最好的失效策略。

    显示失效:如果不能接受脏数据,那么在更新原始数据时同时使缓存失效

    写——失效:标记缓存数据已经过期(是否清理缓存数据是可选的)。

    写——更新:更新数据时替换掉缓存项

    读时失效:采用对象版本控制

    缓存对象分层:分层缓存对象对检索、失效和内存利用都有帮助,相对于只缓存对象,也可以缓存对象的ID、对象的ID组等需要一起检索的数据

    预生成内容:在后台预先请求一些页面,并将结果存为静态页面。

    作为基础组件的缓存

    使用handlerSocket 和memcached:handlerSocketto 刚刚一个简单的协议访问innodb handler 绕过上层的服务器层,

    通过网络直接连接innodb引擎,通过memcached协议访问innoDB

最新回复(0)
/jishuDCSXILi7AbvERvelN_2Bssr6iL4h5Mnkna9uoQBPwlrDE_3D4794805
8 简首页