2019/04/17 事务日志和相关日志

最新推荐文章于 2024-07-10 14:49:09 发布

48N6E

最新推荐文章于 2024-07-10 14:49:09 发布

阅读量296

点赞数

CC 4.0 BY-SA版权

分类专栏： MYSQL事务与数据库备份

本文链接：https://blog.youkuaiyun.com/qq_42227818/article/details/89366129

MYSQL事务与数据库备份专栏收录该内容

6 篇文章

订阅专栏

本文探讨了数据库事务日志的重要性和管理策略，包括事务日志的大小调整、位置选择及与数据文件的分离，以提高数据库性能和安全性。同时，讲解了不同类型的日志，如错误日志、通用日志和二进制日志的作用。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

如果现在有两个终端都开启事务
在这里插入图片描述
去尝试更改表

另外一个终端看到的还是旧的

因为默然的级别是可重复读，那么这个用户能去修改记录吗，不能，因为之前修改的是所有记录

所有记录会在所有行上加锁

那万一这个程序一直占用数据一直全部锁着，导致其他用户都登录不上，就需要我们取发现，
在这里插入图片描述

这个程序一直占用，就需要去kill掉
在这里插入图片描述

没提交的事务杀掉了
应该是之前那个不干活的，因为是全部更改都上锁了

杀掉这个4就代表之前给每个行都上锁的操作

如果有远程用户可以看到这个用户是从哪台主机上链接的

对数据库进行修改都有事务日志，而事务日志就记录了数据的修改
当你对数据进行修改的时候，先把数据从磁盘上读到内存里，在内存里进行修改，改完之后不会立即写到磁盘里，而是把你这个操作写道日志中，在日志里记录了操作，改了多少次就会在数据库里进行追加
由于是追加操作，而不是跑到磁盘上找这个文件，相对来讲速度是比较快的
而数据库存放的，就需要找磁盘上寻找位置，写操作写到磁盘里就需要找一下磁盘上的位置
写到日志里有好处，就是系统奔溃了，还能用日志去恢复
在这里插入图片描述
理论上事务日志和你的数据存放最好不要在一个位置，最好是两块磁盘，这样，如果数据库磁盘坏了，还能从日志中恢复
分开还能起到互不影响的作用

预写式日志式先于数据写的，先写日志，再写数据
在这里插入图片描述

对mysql数据库操作的日志在这里

跟踪一下

这个命令在日志里追加了吗

不会立即追加，当你退出才会写进去
缺点是，只是记录在这台电脑上的操作

既然是事务日志，那么对应的存储引擎也要支持事务日志，myisam是不支持事务的，只有innodb这样的才支持事务日志，事务日志对数据库记录的是修改操作，有redo日志，和undo日志
redo：事务做完但是还没放到数据库的数据文件中，这时候就从事务日志中重新执行，把它和数据文件同步
undo：事务没做完，比如系统崩溃了，就撤销了
上面redo
下面undo
在这里插入图片描述

查看相关变量

innodb_log_block_size 事务日志的块大小，一次最小分配512字节的块
innodb_log_buffer_size 缓存大小，想要往磁盘写文件，会先放到buffer里，buffer写满了再写磁盘，这样效率更高
innodb_log_file_size 事务日志的大小默认5M
innodb_log_files_in_group 在事务日志组里，最多有几个文件
innodb_log_group_home_dir 事务日志存放路径
一般生产中都需要调大事务日志在这里插入图片描述

0写满了，往1 写，1写慢了，把0覆盖，这样轮流，所以就需要修改文件大小
万一你有100M事务，而你的事务日志只有10M大小，就不能回滚
建议在生成中必须要调大，个数也要调多，一般放在raid上，有容错性
oracle数据库日志更专业，可以分为多组

在这里插入图片描述
设置每个事务日志1G，有3个，这样最多就可以放3个G事务

不支持动态更改，只能写到文件里

在这里插入图片描述
修改好后把服务重启，有问题。可能变量名字不叫这个，查看官方文档

报错，不支持的存储引擎

改改数据库日志的目录

现在把数据库都迁移过去

之前报错可能是因为，文件不是干净文件，已经有两个了
在这里插入图片描述
原来的日志就没用了，可以删除

这次回到原来的目录

现在是没用日志的

这次改成4个文件

重启服务

成功，之前失败可能跟之前我们已经存在日志有关

一般情况下，生产建议三个以上
这个事务日志是在线日志，就是会不断地往里面写数据，如果当事务日志文件慢了，又回去覆盖事务日志文件，只保留最近一部分的文件
所以利用事务日志只能保留最近的的发生的事件，不能说，现在把数据库一张大表删除了，利用事务日志是还原不了的
利用事务日志最多只能防止系统崩溃，比如突然断电，把那些没提交的事务日志撤销，提交的事务日志重做，防止不了对数据库的误操作
所以对应这种问题，我们就有二进制日志，通常情况下二进制日志是没有启用的

在这里插入图片描述
中继日志是实现主从复制的，临时用的一个数据日志

错误日志系统默认存放在/var/log/mariadb/mariadb.log

x下面是默认的路径，上面是创建的，创建好文件记得给mysql权限

进行操作前一定要确保这个目录mysql是由写权限的
在这里插入图片描述
把下面的注释

重启服务

生成了错误日志

里面的内容因该是之前的错误信息

错误日志在执行的时候，是否认为警报信息也记录日志呢

超了会有警报，那么这个警报是否记录日志
在这里插入图片描述

**这个警报记录的是
和mysql之前记录的是warning不同
是记录的当mysql数据库进行变更的时候，默认的警报信息是否提供日志
**

这里面记录的内容是mysql服务器工作中遇到的各种问题
创建一个用户

用另外一台机器链接
在这里插入图片描述

想过要把这个查询记录下来，把任何操作都记录下来

general_log是通用日志的意思，默认OFF是不记录

是全局的不是session级别的

想永久生效就放到my.cnf

多一个文件

查看文件内容，现在还是空的
在这里插入图片描述

进行操作就有记录了

这个时候通过哪个主机操作都能记录这个文件信息

通用日志就是谁操作都能记录，如果一直启用那么压力是比较大的，只有排错的使用

不仅可以把日志记录在文件里，事实上还可以把日志，对数据库操作的日志放到一个数据库里
基于表的方式，记录在文件里，只能用文本文件操作
在这里插入图片描述
session、级别不支持，只能全局，这个是是否启用表记录

将记录在表里面，在别的主机上没有退出，但是已经生效了

再去查询一下，看是否记录操作
记录已经生成

事务日志问题，假设每个事物日志都是5M，有一个100M大的事务，做完以后能否撤销
在这里插入图片描述
现在来试试，把当前的事务恢复到默认设置

都删除，恢复到两个日志文件
在这里插入图片描述
如何生成一个大事务

concat是mysql数据库的函数，作用是用来连接字符串和数字的

这样是指定数据库，但是没有用到事务

还是进入MySQL数据库开启事务执行
innode_file_per_table是每张表数据都跟没每张表在一起，而不是默认放在ibtable里
在这里插入图片描述

之前分开的就分不开了，只能删除，重新创建

重新创建数据库

这样每个表都有单独的数据文件了

创建了test表就生成了文件

开启一个事务

进行操作

现在是还没执行，这个存储过程，要执行就需要用到call
在这里插入图片描述

数据生成

数据的文件一直在变大

但是事务日志只有10M，现在提交了那么多，能否回滚，撤销

数据没变
还在

删除数据

变小了

默认就是隐式事务直接提交

数据库表就变大了
在这里插入图片描述
这次用delete删除

现在还是12M

对数据库有大量操作的时候，有可能数据会造成很多磁盘碎片，可以用这个命令对磁盘上的文件做下整理，释放。
尤其多数据库数据做了大量的修正或删除的时候，就可以用这个命令来整理数据库
在这里插入图片描述
trancte很危险不记录日志，将来是无法用二进制日志来还原的
虽然操作会往事务日志里写，事务日志超过了，就会自动提交

撤销以后，恢复了

但是大小还是这么大

表明数据量不够大，再去多执行几次
开启事务执行
在这里插入图片描述

查看是否能撤销，可以还原

数据文件还是这么大

清理完后，查看下空间

事务日志也会保存下来，只不过保存到了数据库文件里了
5M，如果超出了范围就放到数据库文件里，可以调大
5M的文件里实际放到的是数据库变化的信息，真正的操作还是在数据库文件里，虽然没提交，但是也在数据库文件里
事务日志确实记录日志，但是要配合数据库文件
在这里插入图片描述】
事务myisam不支持