Mysql 体系结构系列之十二

前言：参考Mysql体系结构系列之十一：细看核心模块

http://blog.csdn.net/nature_ann/article/details/12856581

1. 细看核心模块 Detailed Look at the Core Modules

1.1 Logging Module 日志记录模块

<<---Logging Module—phyfical or logical—binary update log—command log—slow query log-- sql/sql_class.h ----->>

The Logging Module is responsible for maintaining higher-level (logical) logs.

日志记录模块负责维护较高层次的（逻辑）日志。

 

A storage engine may additionally maintain its own lower-level (physical or logical) logs for its own purposes, but the Logging Module would not be concerned with those;

一个存储引擎可能会为了本身的目的，而去额外维护自己的低层次的日志，包括物理或逻辑的日志。但日志记录模块却与此无关。

 

The storage engine itself takes charge. The logical logs at this point include the binary update log (used mostly for replication, otherwise), command log (used mostly for server monitoring and application debugging), and slow query log (used for tracking down poorly optimized queries).

存储引擎自己会负责完成。这里的逻辑日志包括二进制更新日志（大多数时候用于复制等）、命令日志（大多数用于服务器监视和应用程序调试）以及慢查询日志（用于跟踪优化不良的查询）。

 

Prior to version 5.1, the module was contained for the most part by the class MYSQL_LOG, defined in sql/sql_class.h and implemented in sql/log.cc. Version 5.1 brought a rewrite of this module.

在5.1版本之前，模块大部分包含在MYSQL_LOG类中，定义在sql/sql_class.h中，实现在sql/log.cc中。5.1版本重写了这个模块。

 

Now there exists a hierarchy of log management classes, and MYSQL_LOG is a super-class of TC_LOG, both of which are defined in sql/log.h.However, most of the work in logging happens in the binary replication log.

现在有了一个日志管理类体系，MYSQL_LOG是TC_LOG的超类，两者都在sql/log.h中定义。不过，大部分的日志记录都在二进制复制日志中进行。

 

The classes for log event creation and reading for the binary replication log are defined in sql/log_event.h and implemented in sql/log_event.cc. Both the Replication Master and Replication Slave modules rely heavily on this functionality of the Logging Module.

用于二进制复制日志的日志事件创建和读取的类均在sql/log_event.h中定义，并在sql/log_event.cc中实现。主复制服务器和从复制服务器模块都极为依赖日志记录模块的这个功能。

 

Significant changes were made to this module with the introduction of replication.Version 5.0 brought on some changes required for XA transactions. Version 5.1 added the capability to search logs as if they were an SQL table, which required a significant refactoring of this code.

随着复制的引入，该模块发生了巨大改变。5.0版应XA事务的要求作了一些改动。在5.1版增加了日志当作SQL表进行日志搜索的功能，这需要大刀阔斧地重构代码。

 

The binary logging part required significant changes to accommodate row-based replication. At this point it is hard to anticipate where this code is going in the future.

二进制日志记录部分需要进行重大改进，以便实现基于行的复制。在此很难预测代码将来的发展方向。

1.2 Replication Master Module 主复制服务器模块

<<--- Replication Master Module-- replication functionality- replication log events -- sql/sql_repl.cc - mysql_binlog_send( )-------->>

 

The Replication Master Module is responsible for the replication functionality on the master. The most common operation for this module is to deliver a continuous feed of replication log events to the slave upon request.

主复制服务器模块负责实现主服务器上的复制功能。该模块最常用的功能就是根据请求不断向从服务器发送复制日志事件。

 

Most of the code is found in sql/sql_repl.cc. The core function is mysql_binlog_send( ).

大部分代码在sql/sql_repl.cc中。核心函数为mysql_binlog_send().

 

The module was added in version 3.23, and it has not experienced any major changes other than a thorough cleanup to isolate chunks of code into functions.

3.23版中增加了该模块，但该模块还没有经历过大幅改动，除了进行过一次彻底的清理，将一些代码段独立为函数。

 

In the beginning, the code had very ambitions development plans for fail-safe replication.

起初，大家制定了雄心勃勃的开发计划，打算实现故障安全复制。

 

However, before those plans could be realized, MySQL acquired NDB Cluster code from Ericsson, and began pursuing another route to the eventual goal of automatic failover.

然而，没等实现这些计划，MySQL就收购了爱立信的NDB Cluster代码，并开始寻找其他途径在最终实现自动故障切换。

 

In light of those developments, it is not clear at this point how the native MySQL replication will progress.

根据这些发展情况，目前还不清楚MySQL本身的复制特性将如何发展。

1.3 Replication Slave Module 从复制服务器模块

<<--- Replication Slave Module-- retrieve updates- two-threaded（network I/O thread | SQL thread）-- handle_slave_io( )-- handle_slave_sql( )----->>

 

The Replication Slave Module is responsible for the replication functionality of the slave. The role of the slave is to retrieve updates from the master, and apply them on the slave.

从复制服务器模块负责实现从服务器的复制功能。从服务器的任务是从主服务器处检索更新，并将这些更新应用在从服务器上。

 

The slave starting in version 4.0 is two-threaded. The network I/O thread requests and receives a continuous feed of updates from the master, and logs them in a local relay log.

从4.0版本开始，从服务器使用两个线程。网络I/O线程请求并接收来自主服务器的源源不断的更新，并将更新记录在本地中继日志中。

 

The SQL thread applies them as it reads them from the relay logs.The code for this module is found in sql/slave.cc.

SQL线程从中继日志中读取这些更新时，就会应用这些更新。这一模块的代码在sql/slave.cc中。

 

The most important functions to study are handle_slave_io( ) and handle_slave_sql( ).

需要研究的最重要的函数是handle_slave_io()和handle_slave_sql()。

 

The module was added in 3.23 along with the Replication Master module.

本模块随同主复制服务器模块一起加入3.23版本中。

 

It went through a substantial change in version 4.0 when the monolithic slave thread was broken down into the SQL thread and the I/O thread.

在4.0版本中，当将单一从服务器线程拆分为SQL线程和I/O线程时，本模块进行过大幅度更改。

 

待续。。。