微信公众号搜"智元新知"关注
微信扫一扫可直接关注哦!

MySQL innodb事务的实现方式

这篇文章主要讲解了“MySQL innodb事务的实现方式”,文中的讲解内容简单清晰,易于学习与理解,下面请大家跟着小编的思路慢慢深入,一起来研究和学习“MysqL innodb事务的实现方式”吧!

 【1】Redo Log
 在Innodb存储引擎中,事务日志是通过redo和innodb的存储引擎日志缓冲(Innodb log buffer)来实现的,当开始一个事务的时候,会记录该事务的lsn(log sequence number)号; 当事务执行时,会往InnoDB存储引擎的日志
 的日志缓存里面插入事务日志;当事务提交时,必须将存储引擎的日志缓冲写入磁盘(通过innodb_flush_log_at_trx_commit来控制),也就是写数据前,需要先写日志。这种方式称为“预写日志方式”,
 innodb通过此方式来保证事务的完整性。也就意味着磁盘上存储的数据页和内存缓冲池上面的页是不同步的,是先写入redo log,然后写入data file,因此是一种异步的方式。通过 show engine innodb status\G 来观察之间的差距


 -- 建立一张表z,然后建立一个往表导入数据的存储过程load_test。通过命令show engine innodb status观察当前的redo日志情况

create table z(a int, primary key(a))engine=innodb;

DELIMITER $$
DROP PROCEDURE IF EXISTS `test`.`load_test`$$
CREATE PROCEDURE load_test(COUNT INT)
BEGIN
  DECLARE i INT UNSIGNED DEFAULT 0;
  START TRANSACTION;
  WHILE i < COUNT DO
	REPLACE INTO z SELECT i;  -- 用replace是因为需要重复调用,避免主键重复insert报错。
   	SET i=i+1;
	END WHILE;
 COMMIT;
END;
$$


 

......
---
LOG
---
Log sequence number 20499052099  当前的LSN
Log flushed up to   20499052099  表示刷新到redo log的LSN
Pages flushed up to 20499052099  表示刷新到磁盘的lsn
Last checkpoint at  20499052099  
0 pending log writes, 0 pending chkp writes
373 log I/O's done, 0.00 log I/O's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 137363456; in additional pool allocated 0
Dictionary memory allocated 1270857
Buffer pool size   8191
Free buffers       7562
Database pages     612
Old database pages 205
Modified db pages  0
Pending reads 0
......


MysqL> call test.load_test(100000);
Query OK, 0 rows affected, 1 warning (6.28 sec)

MysqL> show engine innodb status\G
...... 
---
LOG
---
Log sequence number 20504734913
Log flushed up to   20504734913
Pages flushed up to 20504734913
Last checkpoint at  20504734913
0 pending log writes, 0 pending chkp writes
398 log I/O's done, 0.38 log I/O's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
...... 
看来Log sequence number和Log flushed up以及Pages flushed u3个还是一样的。

再多导入点数据,重新开启另外一个窗口看看innodb状态
MysqL> call test.load_test(1000000);
MysqL> show engine innodb status\G
......
---
LOG
---
Log sequence number 20527044411
Log flushed up to   20525763843
Pages flushed up to 20517902997
Last checkpoint at  20504829471
0 pending log writes, 0 pending chkp writes
432 log I/O's done, 1.26 log I/O's/second
----------------------
BUFFER POOL AND MEMORY
----------------------

这次看到的show engine innodb status的结果就不一样了,Log sequence number > Log flushed up > Pages flushed up > Last checkpoint,所以从这里也可以看出,先写redo日志,再写数据文件
在实际写比较频繁的productiion上面,这3个值都会是不一样的。

【2】Undo 
undo的记录正好与redo的相反,insert变成delete,update变成相反的update,redo放在redo file里面。而undo放在一个内部的一个特殊segment上面,存储与共享表空间内(ibdata1或者ibdata2中)。
py_innodb_page_info.py
下载地址: wget http://david-MysqL-tools.googlecode.com/svn-history/r15/trunk/py_innodb_page_type/py_innodb_page_info.py
[root@MysqL data56]# python /root/py_innodb_page_info.py /data56/ibdata1 
Traceback (most recent call last):
  File "/root/py_innodb_page_info.py", line 3, in <module>
    import mylib
ImportError: No module named mylib
[root@MysqL data56]# 
还需要下载 mylib.py和include.py文件,并和py_innodb_page_info.py放在一个目录之下

wget http://david-MysqL-tools.googlecode.com/svn-history/r15/trunk/py_innodb_page_type/mylib.py
wget http://david-MysqL-tools.googlecode.com/svn-history/r15/trunk/py_innodb_page_type/include.py
ps:有的时候network会断掉,要多执行几次wget去下载。

[root@MysqL ~]#  python /root/py_innodb_page_info.py /data56/ibdata1

Total number of page: 8960:
Insert Buffer Free List: 1035
Insert Buffer Bitmap: 1
System Page: 134
Transaction system Page: 1
Freshly Allocated Page: 4010
Undo Log Page: 1556
File Segment inode: 5
B-tree Node: 2217
File Space Header: 1
[root@MysqL ~]# 
[root@MysqL ~]#

undo不是物理恢复,是逻辑恢复,因为它是通过执行相反的dml语句来实现的。而且不会回收因为insert和upate而新增加的page页的。
undo页的回收是通过master thread线程来实现的。

验证row模式下,生产的binlog传到从库上面,大概需要多久!
导出
time /usr/local/MysqL56/bin/MysqLdump --socket=/data56/MysqL.sock -uroot -p123456 -P3307 --extended-insert=false --all-databases> /root/adb.sql
[root@MysqL ~]# time /usr/local/MysqL56/bin/MysqLdump --socket=/data56/MysqL.sock -uroot -p123456 -P3307 --extended-insert=false --all-databases> /root/adb.sql
Warning: Using a password on the command line interface can be insecure.


real    5m10.757s
user    2m42.137s
sys     0m11.346s

导入
time /usr/local/MysqL56/bin/MysqL --socket=/data56/MysqL.sock -uroot -p123456 -P3307 < /root/adb.sql
在从库上面检查:
MysqL> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 10.88.49.119
                  Master_User: repl
                  Master_Port: 3307
                Connect_Retry: 60
              Master_Log_File: MysqL56-bin.000008
          Read_Master_Log_Pos: 513272653
               Relay_Log_File: MysqL56-relay-bin.000019
                Relay_Log_Pos: 103964146
        Relay_Master_Log_File: MysqL56-bin.000008
             Slave_IO_Running: Yes
            Slave_sql_Running: Yes
              Replicate_Do_DB: 
          Replicate_Ignore_DB: 
           Replicate_Do_Table: 
       Replicate_Ignore_Table: 
      Replicate_Wild_Do_Table: 
  Replicate_Wild_Ignore_Table: 
                   Last_Errno: 0
                   Last_Error: 
                 Skip_Counter: 0
          Exec_Master_Log_Pos: 418536570
              Relay_Log_Space: 513273109
              Until_Condition: None
               Until_Log_File: 
                Until_Log_Pos: 0
           Master_SSL_Allowed: No
           Master_SSL_CA_File: 
           Master_SSL_CA_Path: 
              Master_SSL_Cert: 
            Master_SSL_Cipher: 
               Master_SSL_Key: 
        Seconds_Behind_Master: 857
Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error: 
               Last_sql_Errno: 0
               Last_sql_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 11901
                  Master_UUID: a6a1d870-80b5-11e2-84d2-00155d016a07
             Master_Info_File: /data56/master.info
                    sql_Delay: 0
          sql_Remaining_Delay: NULL
      Slave_sql_Running_State: System lock
           Master_Retry_Count: 86400
                  Master_Bind: 
      Last_IO_Error_Timestamp: 
     Last_sql_Error_Timestamp: 
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
           Retrieved_Gtid_Set: 
            Executed_Gtid_Set: 
                Auto_Position: 0
1 row in set (0.00 sec)


ps:Seconds_Behind_Master: 857,有延时的情况出现,可见在row模式下,import6G的单调insert的sql的时候,有延时。

感谢各位的阅读,以上就是“MysqL innodb事务的实现方式”的内容了,经过本文的学习后,相信大家对MysqL innodb事务的实现方式这一问题有了更深刻的体会,具体使用情况还需要大家实践验证。这里是编程之家,小编将为大家推送更多相关知识点的文章,欢迎关注!

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐