Inception的备份语句生成原理分析

Posted 2020-10-08

Inception是对mysql数据库的线上运维操作进行辅助的一个工具，它能提供SQL的审核、执行、备份的操作，保证运维的可靠性。

现在为了在公司中使用这个工具来减轻我们的运维工作负担，开始着手使用它。

问题

使用之前，我们需要了解这个工具的原理，包括它对一些我们关注的方面的解决方式，以及在出现一些问题时我们应该怎样应对解决。

• 首先，我们需要用到它的审核SELECT类型SQL功能，那么它的审核功能是怎么实现的？一些审核配置项是怎么发生作用的？
• 其次，我们还需要用到它的DML操作功能，Inception是怎样完成在审核SQL的同时还能执行？执行完成后是怎么生成反向恢复语句？如果在执行多条语句的时候中途发生了错误，后续的语句还会执行吗？如果在执行过程中网络发生问题，执行结果又是怎样的？
• 等等。。。

带着这些问题，我们开始一点点探索它内部的一些细节流程。

代码分析

我们先从执行函数的创建阶段开始查找，找到执行流程的具体入口在什么位置，以及这个具体入口是怎样被创建的。

• 执行流程创建

通过GDB的定位以及代码的分析，我们可以得到Inception的具体工作是在新创建的工作线程中完成，而这个工作线程的入口钩子函数就是实际的处理函数：

 而钩子函数的挂钩的过程是在进程刚启动时的初始化函数中完成的：

根据上面两个流程图，我们得到的结论是Inception在启动成功后，一旦接收到SQL语句的请求，就会创建新的线程，而这个创建新线程的钩子函数是指向create_thread_to_handle_connection(), 在这个函数会创建线程来处理对SQL语句块的分析、检查、执行和备份流程。

• 执行SQL流程分析

在create_thread_to_handle_connection()函数中，新创建的线程入口函数为handle_one_connection()，从这个函数中，我们可以继续查找到SQL语句块的分析、检查、执行和备份流程以及回滚语句的具体执行位置，执行流程图如下所示：

上图从左往右的顺序就是函数栈的从上往下的顺序，一直到最底层实现具体逻辑的地方。

以下内容会对这个图的各个部分进行拆解分析。

• SQL检查流程

当Inception监听的端口收到连接请求后，就会调用create_new_thread()函数，其中创建的新线程的入口函数钩子已经在Inception的main函数开始阶段确定下来，它是指向handle_one_connection()函数。

在handle_one_connection()函数中，会将输入的SQL语句进行处理（语法词法解析、检查规范、执行、备份语句等操作），处理完成后将结果给传回到客户端。

在一个Inception语句块中，一定会包含多条语句，因为它需要满足以下格式的语句块：

1 /*--user=inception_user;--password=123456;--host=192.168.1.200;--enable-execute;--port=3363;*/ 
2 inception_magic_start;
3 use test_2;
4 update test set name="aaaaab" where id=20; 
5 inception_magic_commit;

第1行是Inception语句块的头信息，放在SQL的注释块中

第2行是Inception语句块的起始标记

第3~4行是Inception语句块，客户端需要处理的SQL语句

第5行是Inception语句块的结束标记

头信息、开始标记、结束标记必然是需要的，语句块信息也至少是1句SQL，每条语句经过语法解析后，会得到一棵语法树，交由mysql_process_command()进行处理。

此函数对每个语句生成的语法树都会进行处理，在处理到Inception_magic_commit对应的语法树之前，都是检查的过程，只有在处理完它之后才会进行执行（如果在头信息中指定的是--enable-check而不是--enable-execute后续就不会有执行的操作发生了，只是将得到的检查结果发回给客户端）。

在mysql_parse()中生成了一条语句的语法树后，会继续执行对这条语句的处理流程，其中检查过程是在mysql_check_command()函数中完成的，包括检查dml语句是否有where条件(inception_check_dml_where)、inception_check_dml_limit、inception_check_dml_orderby、inception_enable_select_star等等检查项。

• 执行流程

在对所有语句的检查完成后，会进入到mysql_execute_commit()函数，开始进行所有语句的执行，每条语句按照顺序执行，并且每条语句都是独立的事务，如果中途有一条语句发生错误，后续的语句就不会执行了。

如果在执行过程中发生网络问题，那么这条语句对应到这个事务是否完成是未知的，但是对于Inception而言，发生网络错误了就相当于这条语句执行失败，后续的语句就不会执行了，当前的这条语句会标记为失败，也就不会有回滚语句备份。

• 生成回滚语句流程

在执行过程完成后，就开始对每条语句逐个进行回滚语句解析并备份：

从下图中可以看出备份是在执行完成之后，在mysql_backup_sql()中逐条解析语句的binlog，对于每个语句在执行的过程中记录了该语句执行之前的binlog pos和之后的binlog pos，以及该连接的thread_id, 使用这三个值可以对每条语句的binlog进行精确定位，从而可以得到这个语句的所有binlog。

每条语句的binlog中可能包含多个event，每个event可以解析出一条回滚语句。

如果在binlog的传输过程中发生网络错误，Inception给每条语句的备份流程中进行重试的机会有三次，如果重试次数超过三次，这条语句的回滚语句就会备份失败。

 

上面这张图是Inception的回滚语句备份流程，会对不同的语句类型执行不同的event解析过程。具体的解析过程后续会有文章再分析。

结论

这篇文章从Inception的DML语句的检查、执行、备份的实现流程的角度去分析了它的源码执行流程：

检查过程是在mysql_check_command()过程中完成的，这个过程发生在每条语句的语法树生成之后，在执行所有语句之前。

执行过程是在mysql_execute_commit()函数中完成，在这个函数中会在线上服务器上逐条执行每个sql语句，执行结果中会包含执行前的binlog位置和执行后的binlog位置以及thread_id

备份过程是在执行过程完成之后，逐条语句分析对应的binlog（流式下载到Inception端），然后根据在执行时记录的执行前binlog位置和执行后的binlog位置以及thread_id来得到属于这条语句的所有binlog，解析为回滚语句并备份到备份服务器上。

通过源码的分析，在后面的使用中如果碰到了一些问题可以很容易定位，如果有需要的话直接上手改也是一个不错的选择，即解决了自己的问题也为开源工具的发展做出一点贡献。