mysql 第12天 分布式事务的使用 SQL中的安全问题

分布式事务

当前分布式事务只支持innodb存储引擎。

分布式事务会涉及多个行动，这些行动本省是事务性的。所有行动都必须一起成功完成，或者一起被回滚

分布式事务的原理

1     分布式原理涉及到一个或多个资源管理器和一个事务管理器

·资源管理器(RM)用于提供通向事务资源的途径。数据库服务器是一种资源管理器。
该管理器必须可以提交或回滚由 RM 管理的事务。例如,多台 MySQL 数据库作为多台资源
管理器或者几台 Mysql 服务器和几台 Oracle 服务器作为资源管理器。
·事务管理器(TM)用于协调作为一个分布式事务一部分的事务。TM 与管理每个事务
的 RMs 进行通讯。一个分布式事务中各个单个事务均是分布式事务的“分支事务”。分布式
事务和各分支通过一种命名方法进行标识。

2       MySQL 执行 XA MySQL 时,MySQL 服务器 相当于一个用于管理分布式事务中的 XA 事务
的资源管理器。与 MySQL 服务器连接的客户端相当于事务管理器。

3       管理一个分布式事务，必须考虑任何组件或连接网络的可能故障

4  执行分布式事务使用两阶段提交，发生在各个分支需要的行动已经被执行

 在第一阶段,所有的分支被预备好。即它们被 TM 告知要准备提交。通常,这意味
着用于管理分支的每个 RM 会记录对于被稳定保存的分支的行动。分支指示是否它们可以这
么做。这些结果被用于第二阶段。
 在第二阶段,TM 告知 RMs 是否要提交或回滚。如果在预备分支时,所有的分支指
示它们将能够提交,则所有的分支被告知要提交。如果在预备时,有任何分支指示它将不能
提交,则所有分支被告知回滚。

5    在有些情况下,一个分布式事务可能会使用一阶段提交。例如,当一个事务管理器发现,
一个分布式事务只由一个事务资源组成(即单一分支)

分布式事务的语法

分布式事务(XA 事务)的语法

1      XA {START|BEGIN} xid [JOIN|RESUME]

XA START xid 用于启动一个带给定 xid 值的 XA 事务。每个 XA 事务必须有一个唯一的 xid
值,因此该值当前不能被其他的 XA 事务使用。

2  xid是一个XA事务标示符，唯一标示一个分布式事务

xid: gtrid [, bqual [, formatID ]]

 gtrid 是一个分布式事务标识符,相同的分布式事务应该使用相同的 gtrid,这样可以
明确知道 xa 事务属于哪个分布式事务。
 bqual 是一个分支限定符,默认值是空串。对于一个分布式事务中的每个分支事务,
bqual 值必须是唯一的。
 formatID 是一个数字,用于标识由 gtrid 和 bqual 值使用的格式,默认值是 1。

下面使用的语法中用到的xid，都必须和start 操作使用的xid相同

3

XA END xid [SUSPEND [FOR MIGRATE]]

XA PREPARE xid

使事务进入 PREPARE 状态,也就是两阶段提交的第一个提交阶段

4

XA COMMIT xid [ONE PHASE]
XA ROLLBACK xid

这两个命令用来提交或者回滚具体的分支事务。也就是两阶段提交的第二个提交阶段,
分支事务被实际的提交或者回滚。

5

XA RECOVER

XA RECOVER 返回当前数据库中处于 PREPARE 状态的分支事务的详细信息

分布式的关键在于如何确保分布式事务的完整性,以及在某个分支出现问题时的故障解
决

存在的问题

1      如果分支事务在达到 prepare 状态时,数据库异常重新启动,服务器重新启动以后,可
以继续对分支事务进行提交或者回滚得操作,但是提交的事务没有写 binlog,存在一定的隐
患,可能导致使用 binlog 恢复丢失部分数据。

2     如果分支事务的客户端连接异常中止,那么数据库会自动回滚未完成的分支事务,如果
此时分支事务已经执行到 prepare 状态,那么这个分布式事务的其他分支可能已经成功提交,
如果这个分支回滚,可能导致分布式事务的不完整,丢失部分分支事务的内容

3     如果分支事务在执行到 prepare 状态时,数据库异常,且不能再正常启动,需要使用备
份和 binlog 来恢复数据,那么那些在 prepare 状态的分支事务因为并没有记录到 binlog,所
以不能通过 binlog 进行恢复,在数据库恢复后,将丢失这部分的数据。

总之, MySQL 的分布式事务还存在比较严重的缺陷,在数据库或者应用异常的情况下,
可能会导致分布式事务的不完整

SQL中的安全问题

如果SQL语句写作不当，会造成很大隐患，最大的隐患为   SQL注入

SQL注入简介

1             SQL Injection 就是利用
某些数据库的外部接口将用户数据插入到实际的数据库操作语言(SQL)当中,从而达到入
侵数据库乃至操作系统的目的。它的产生主要是由于程序对用户输入的数据没有进行严格的
过滤,导致非法数据库查询语句的执行。

2      SQL注入的危害也很大

可以采取的措施

1      对 Java、JSP 开发的应用,可以使用 PrepareStatement+Bind-variable 来防止 SQL 注入

2      使用应用程序提供的转换函数

 MySQL C API:使用 mysql_real_escape_string() API 调用。
 MySQL++:使用 escape 和 quote 修饰符。
 PHP:使用 mysql_real_escape_string()函数

 Perl DBI:使用 placeholders 或者 quote()方法。
 Ruby DBI:使用 placeholders 或者 quote()方法。

3   自己定义函数进行校验

 整理数据使之变得有效;
 拒绝已知的非法输入;
 只接受已知的合法输入。

所以如果想要获得最好的安全状态,目前最好的解决办法就是对用户提交或者可能改
变的数据进行简单分类,分别应用正则表达式来对用户提供的输入数据进行严格的检测和验
证。

非法符号有：

“’”、“;”、“=”、“(”、“)”、“/*”、“*/”、“%”、“+”、“”、“>”、“<”、“--”、“[”、“]”;