求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
  
 
 
     
   
分享到
MySQL Replication和Oracle logical standby的原理对比
 

作者:linwaterbin,发布于2012-12-24,来源:CSDN

 

MySQL Replication和Oracle logical standby都是SQL apply,那么在实现上有何区别?

Binary Log 和 Redo的传输原理

MySQL Replication可以很方便的用来做应用的读扩展,也可以帮MySQL实现一定程度的HA方案整个复制过程实际上就是Slave从Master端抓取Binary Log然后再在自己身上完全顺序的执行日志中所记录的各种操作

㈠ 如何同步?

主库将所有的更新操作,写入二进制日志。

从库运行"IO线程"(Slave IO Thread)读取主库的二进制日志。

从库运行"SQL线程"(Slave SQL Thread)执行IO线程(Slave IO Thread)读取的日志中的SQL,从而保持和主库的事务一致

㈡ 如何分配请求?

目前,这部分需要在应用层实现。

执行更新SQL(UPDATE,INSERT,DELETE)时,请求主库

执行查询SQL(SELECT)时,请求从库

所以,当你的应用(Application)SELECT请求所占的比率越大,那么Relication就会越有效

㈢ MySQL如何传输二进制日志,是主库推,还是备库拉?MySQL日志传输的实时性如何?

在MySQL Replication结构中,备库端初次通过CHANGE MASTER TO完成Replication配置,再使用start slave命令开始复制
更细致的:

① Slave上的IO Thread连接上Master,并向Master发起读取Binary Log的请求(COM_BINLOG_DUMP命令),从指定日志文件的指定位置(或者最开始的日志)之后的日志内容

② Master收到COM_BINLOG_DUMP请求后,使用dump thread不断向Slave IO Thread发送Binary Log(指定日志文件的指定位置之后的日志信息)返回信息中除了日志所包含的信息之外,还包括本次返回的信息在Master的Binary Log的文件名称以及在Binary Log中的位置
③ 在Master一旦有新的日志产生后,立刻会发送一次广播,dump thread在收到广播后,则会读取二进制日志并通过网络向Slave传输日志

④ Slave的IO thread接收到信息后,将接收到的日志内容依次写入到Slave的Relay Log文件(mysql-relay-bin.xxxxxx)的最末端。并将读取到的Master的Binary Log的文件名和位置记录到master-info文件中,以便在下次读取的时候能够清楚地告诉Master:
“俺们需要从某个Binary Log的哪个位置开始往后的日志内容,请发给我”

⑤ Slave的SQL thread检测到Relay Log中新增加了内容后,会马上解析Log文件中的内容成为在Master真实执行时候的那些可执行的Query语句,并在自身执行这些Query。这样,实际上就是在Master和Slave执行了同样的Query,所以两端的数据完全一样。
所以这是一个主库向备库不断推送的过程

新日志在产生后,只需一次广播和网络就会立刻(<1ms)向发送到备库,如果主备之间网络较好的话(例如RTT<1ms),备库端的日志也就小于2ms了

所以,一般的(依赖于RTT),备库的实时性都非常好。

注释:

RTT(Round-Trip Time): 往返时延,在计算机网络中它也是一个重要的性能指标,它表示从发送端发送数据开始,到发送端收到来自接收端的确认(接收端收到数据后便立即发送确认),总共经历的时延对于Oracle,在primary,DataGuard可以使用归档进程(ARCn)或者日志写进程(LGWR)收集redo数据并传输到standby

㈠ 使用ARCn归档redo数据

缺省情况下,RTS使用ARCn进程归档redo日志。不过ARCn归档进程只支持最高性能的保护模式primary日志发生切换时就会启动归档:

  • 在primary(假设有2个归档进程),一旦ARC0进程完成redolog的归档,ARC1进程即开始传输该归档到standby的指定路径
  • 在standby,RFS进程轮流将redo数据写入standby log,再由standby中的ARCn进程将其写入归档,然后通过SQL apply将数据应用到standby数据库

㈡ 使用LGWR归档实时同步redo数据

使用LGWR进程与使用ARCn进程有明显不同,LGWR无须等待日志切换及完成归档

  • 在primary,LGWR提交redo数据到LNSn(LGWR Network Server process)进程(n>0),LNSn启动网络传输
  • 在standby的RFS(Remote File Server)将接收到的redo数据写入standby log。在此期间,primary的事务会一直保持,直到所有含LGWR SYNC属性的LOG_ARCHIVE_DEST_n指定路径均已完成接收

㈢ 使用LGWR归档异步redo数据

大致步骤与同步传输相同,差别只在LNSn进程这里,LGWR写数据到online redolog

LNSn进程访问online redolog并传输数据到远程standby的RFS而不再与本地LGWR之间有联系standby数据库方面的处理逻辑仍然不变

复制实现级别和数据保护模式

MySQL Replication可以是基于statement level,也可以基于row level不同的复制级别会影响到Master的Binary Log记录成不同的形式

① row level

Binary Log会记录成每一行数据被修改的形式,然后再Slave再对相同数据进行修改

优点:

⒈ Row Level的日志内容会非常清楚的记录下每一行数据修改的细节,非常容易理解

⒉ 不存在某些情况下存储过程或function以及trigger的调用和触发无法被正确复制的问题

缺点:

产生惊人的日志量

② statement level

每一条会修改数据的Query都会记录到Master的Binary Log中。Slave 在复制的时候SQL线程会解析成和原来Master端执行过的相同的Query来再次执行

优点:

减少Binary Log日志量,节约了IO成本,提高了性能

缺点:

⒈ 必须级联记录每条语句在执行时的上下文信息

⒉ 存在某些情况下存储过程或function以及trigger的调用和触发无法被正确复制的问题

Data Guard提供了三种数据保护的模式

① 最大保护(Maximum protection):

所有的事务在提交前至少一个standby数据库redo数据被同步写入

如果出现了什么故障导致standby数据库不可用的话,primary数据库会被shutdown

② 最高性能(Maximum performance):

事务可以随时提交,当前primary数据库的redo数据也需要至少写入一个standby数据库,不过这种写入可以是不同步的

③ 最高可用性(Maximum availability):

和maximum protection一样,至少一个standby数据库redo数据被同步写入不过与之不同的是,如果出现故障导入无法同时写入standby数据库redo log,primary数据库并不会shutdown而是自动转为最高性能模式,等standby数据库恢复正常之后,它又会再自动转换成最高可用性模式

相关文章 相关文档 相关视频



我们该如何设计数据库
数据库设计经验谈
数据库设计过程
数据库编程总结
数据库性能调优技巧
数据库性能调整
数据库性能优化讲座
数据库系统性能调优系列
高性能数据库设计与优化
高级数据库架构师
数据仓库和数据挖掘技术
Hadoop原理、部署与性能调优
 
分享到
 
 


MySQL索引背后的数据结构
MySQL性能调优与架构设计
SQL Server数据库备份与恢复
让数据库飞起来 10大DB2优化
oracle的临时表空间写满磁盘
数据库的跨平台设计
更多...   


并发、大容量、高性能数据库
高级数据库架构设计师
Hadoop原理与实践
Oracle 数据仓库
数据仓库和数据挖掘
Oracle数据库开发与管理


GE 区块链技术与实现培训
航天科工某子公司 Nodejs高级应用开发
中盛益华 卓越管理者必须具备的五项能力
某信息技术公司 Python培训
某博彩IT系统厂商 易用性测试与评估
中国邮储银行 测试成熟度模型集成(TMMI)
中物院 产品经理与产品管理
更多...