MySQL Replication和Oracle logical standby的原理对比

电玩女神 2022-05-13 12:50 202阅读 0赞

转载于:[http://blog.csdn.net/linwaterbin/article/details/8229511][http_blog.csdn.net_linwaterbin_article_details_8229511]

MySQL Replication和Oracle logical standby都是SQL apply，那么在实现上有何区别？  
         
        Binary Log 和 Redo的传输原理  
         
        MySQL Replication可以很方便的用来做应用的读扩展，也可以帮MySQL实现一定程度的HA方案  
        整个复制过程实际上就是Slave从Master端抓取Binary Log然后再在自己身上完全顺序的执行日志中所记录的各种操作

![1354641546_7945.png][]

![1353991086_2540.png][]

㈠ 如何同步？  
        
           主库将所有的更新操作，写入二进制日志。  
           从库运行"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，所以两端的数据完全一样。  
          所以这是一个主库向备库不断推送的过程

![1353991169_3600.png][]

新日志在产生后，只需一次广播和网络就会立刻（<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数据库

![1353991238_8937.png][]

㈡ 使用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指定路径均已完成接收

![1353991291_2267.png][]

㈢ 使用LGWR归档异步redo数据  
           大致步骤与同步传输相同，差别只在LNSn进程这里，LGWR写数据到online redolog  
           LNSn进程访问online redolog并传输数据到远程standby的RFS而不再与本地LGWR之间有联系  
           standby数据库方面的处理逻辑仍然不变

![1353991328_8241.png][]

复制实现级别和数据保护模式  
         
        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数据库恢复正常之后，它又会再自动转换成最高可用性模式

[http_blog.csdn.net_linwaterbin_article_details_8229511]: http://blog.csdn.net/linwaterbin/article/details/8229511
[1354641546_7945.png]: https://img-my.csdn.net/uploads/201212/05/1354641546_7945.png
[1353991086_2540.png]: https://img-my.csdn.net/uploads/201211/27/1353991086_2540.png
[1353991169_3600.png]: https://img-my.csdn.net/uploads/201211/27/1353991169_3600.png
[1353991238_8937.png]: https://img-my.csdn.net/uploads/201211/27/1353991238_8937.png
[1353991291_2267.png]: https://img-my.csdn.net/uploads/201211/27/1353991291_2267.png
[1353991328_8241.png]: https://img-my.csdn.net/uploads/201211/27/1353991328_8241.png