驾校网上约车网站开发北京优酷首页培训机构

当前位置： 首页 > news >正文

驾校网上约车网站开发,北京优酷首页培训机构,ftp 修改网站,有口碑的大良网站建设介绍 undo log 和 redo log是由Inno DB存储引擎生成的。 在MySQL服务器架构中#xff0c;分为三层#xff1a;连接层、服务层#xff08;server层#xff09;、执行层#xff08;存储引擎层#xff09; bin log 是 binary log的缩写#xff0c;即二进制日志。 MySQL…介绍 undo log 和 redo log是由Inno DB存储引擎生成的。 在MySQL服务器架构中分为三层连接层、服务层server层、执行层存储引擎层 bin log 是 binary log的缩写即二进制日志。 MySQL在完成一次DML操作后Server层还会生成一条binlog等事务提交之后 还会将该事务执行过程中产生的所有binlog统一写入到binlog日志文件中 binlog日志文件中保存了所有数据库的所有表结构的变化和表数据的变化 bin log的作用 bin log主要用于下面两个方面 主从复制 对于”双11“这种级别的千万级高并发单台数据库服务器是扛不住的 为了提供并发处理的能力一般会部署多态MySQL服务器这些服务器中维护着相同的数据副本。这些MySQL服务器组成一个MySQL集群 一个非常典型的部署方案就是一主多从 在这些MySQL服务器中有一个主服务器Master和多台从服务器Slave 主服务器只负责数据变更而从服务器负责查询在大部分情况下查询是最耗时的因为多台从服务器负责查询操作分担了并发压力。 对于DDL、DML请求将就给主服务器去执行 对于查询Select请求就交给从服务器因为每个服务器中都维护着相同的数据副本所以交给任意一个从服务器即可 为了让各个从服务器中存储的数据 和主服务器中的数据保持一致每当我们改变了主服务器中的表结构或者表数据就需要将这些变更信息同步给各个从服务器此时bin log就发挥作用了 bin log中保存了所有数据库的所有表的变化信息从服务器只需要读取主服务器的bin log就能完成主从服务器之间的数据同步 系统备份恢复 如果不小心把整个数据库的数据都删除了能使用redo log日志恢复数据吗 当然不能因为redo log是Inno DB产生的日志文件Inno DB是表级别的在创建表时指定表的存储引擎当直接删除了整个数据库那么这些redo log日志也不会存在了即使这些redo log存在也并不能将这个表的所有数据都恢复因为redo log日志文件存在复用的情况对于哪些已经刷新到磁盘的redo logredo log已经没有存在的必要性了所以会覆盖掉新写的redo log会覆盖掉之前的旧的redo log因此redo log只能保证恢复在事务提交之前的部分数据 因为 redo log 文件是循环写是会边写边擦除日志的只记录未被刷入磁盘的数据的物理日志已经刷入磁盘的数据都会从 redo log 文件里擦除。 此时又轮到binlog发挥作用了 因为bin log记录了所有库的所有表的变更信息所以可以借助binlog来完成数据恢复 配置使用binlog 查看MySQL服务器是否开启了bin log show variables like log_bin;查询到的值是ON代表当前服务器已开启binlog日志功能如果为OFF代表当前服务器没有开启bin log功能 如果当前服务器没有开启bin log需要手动开启。 关闭服务器重新启动服务器时添加此启动配置项 –log-bin [base_name]base_name是用来记录bin log日志文件的基名称 bin log日志文件会保存在MySQL的数据目录下bin log日志文件不是一个文件而是一组文件这一组文件的命名规则是这样的 basename.000001 basename.000002 basename.000003 basename.000004 ….以basename作为基名称后面的序号递增。 如果需要修改bin log文件的基名称可以利用启动项参数修改 –log-bin [basename]如果没有指定基名称那么MySQL服务器会默认以主机名-bin作为binlog日志文件的基名称。 MySQL 8.x 会默认以binlog作为基名称 binlog.000001 binlog.000002 ….查看binlog中的内容 binlog日志文件并不能直接查看因为是二进制文件。 binlog中记录数据库发生变更的各种事件事件类型非常多其实并不需要刻意关注binlog中的内容。 如果真的想要查看binlog的内容则可以借助MySQL提供的mysqlbinlog工具 mysqlbinlog工具作为可执行文件存放在MySQL安装目录的bin目录下 将需要查看的binlog日志文件作为mysqlbinlog命令的参数 mysqlbinlog ./data/binlog.0000001binlog日志文件格式 随着MySQL版本的更新binlog文件格式也有不同的版本在此以v4最新版本的文件格式来讲解。 一个binlog日志文件的基本格式主要由两部分组成 文件固定头部事件 每个binlog日志文件的前4个字节都是固定的用来作为此文件的一个标识不用关心。每个binlog日志文件都有若干个事件组成这些事件就是对数据库表的变更事件。 每个事件又可以分为两部分 事件头 event header用来对这个事件进行描述的信息真实数据 data 好了这就是binlog日志文件的基本格式知道这么多就行了。 两种binlog binlog日志文件中存储的事件就是对数据库变更的信息那么如何描述这个事件又有两种方式。 一条sql语句如果binlog-format不同那么可能生成不同类型的binlog事件大致就可以分为基于语句Statement和基于行row两种类型的binlog 当以启动选项–binlog-formatSTATEMENT启动MySQL服务器时生成的binlog称作基于语句的日志。此时只会将一条SQL语句将会被完整的记录到binlog中而不管该语句影响了多少记录。 当以启动选项–binlog-formatROW启动MySQL服务器时生成的binlog称作基于行的日志。此时会将该语句所改动的记录的全部信息都记录上。 当以启动选项 –binlog-formatMIXED启动MySQL服务器时生成的binlog称作基于行的日志。此时在通常情况下采用 基于语句的日志 在某些特殊情况下会自动转为基于行的日志
简单总结 基于语句的binlog 只将更新语句是什么记录下来了。基于行的binlog 将更新语句执行过程中每一条记录更新前后的值都记录下来了 基于语句的binlog可能会导致主从数据不一致的情况例如下面这条语句 INSERT INTO t© SELECT c FROM other_table;这条语句是从其他表中查询数据并插入到一张表中。 但是对于这条子查询SELECT c FROM other_table;,可能由于不同服务器版本、不同的系统变量导致同一条语句的结果顺序不同那么在插入时自动生成主键不同的顺序最终生成的记录的主键值不同。 原因是在基于语句的binlog中只会记录这条sql语句从库去执行这条sql语句并不会关心更新前后的记录值。 但是在基于行的binlog中还保存了这条记录更新前后的值从库在执行完sql语句后还会将这条记录调整到一致的状态从而保证主从数据一致性。 redo、undo、buffer pool、binlog的执行顺序 当执行一条UPDATE语句时redo、undo、binlog的写入顺序是怎样的 具体的一条记录的更新流程如下 现在B树中定位到该记录锁定读如果该数据所在的页面不再Buffer pool中则先将这一页数据从磁盘加载到buffer pool中 读取到记录后判断记录更新前后是否一样一样的话就跳过不用更新了 首先更新聚簇索引记录 更新聚簇索引记录时 首先向undo页面写入undo日志因为这是在修改页面所以修改undo页面前需要先记录这次的redo日志真正的更新记录在更新前记录响应的redo日志 更新其他的二级索引
至此一条记录更新完成 redo 和 bin log的区别 适用对象不同 binlog是MySQL的Server层实现的日志是整个MySQL服务器级别的redo log是InnoDB存储引擎实现的日志是表级别的 文件格式不同 写入方式不同
binlog是追加写写满一个文件就会新创建一个文件不会覆盖以前的文件redo log是循环写日志空间的大小是固定的写满了就会从头开始写覆盖掉之前的redo Log内容 用途不同 binlog 主要用于主从复制、备份恢复redo log主要用于发生故障时表脏数据的恢复 主从复制 前面已经介绍过主从复制MySQL的主从复制依赖于bin log 复制过程就是将binlog中的数据从主库传输到从库 这个过程是异步的 [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-rLPw0Yy5-1691478160467)(https://cdn.xiaolincoding.com/gh/xiaolincoder/mysql/how_update/%E4%B8%BB%E4%BB%8E%E5%A4%8D%E5%88%B6%E8%BF%87%E7%A8%8B.drawio.png?image_processwatermark,text_5YWs5LyX5Y-377ya5bCP5p6XY29kaW5n,type_ZnpsdHpoaw,x_10,y_10,g_se,size_20,color_0000CD,t_70,fill_0)] MySQL主从复制的三个步骤 Master 写入binlog主服务器写binlog日志提交事务Slave 同步 binlog把binlog复制到所有从库上每个从库把binlog保存到暂存日志中回访binlog从服务器执行完数据的更新后记录到自己的bin log日志文件中 具体的过程 MySQL 主库在收到客户端提交事务的请求之后会先写入 binlog再提交事务更新存储引擎中的数据事务提交完成后返回给客户端“操作成功”的响应。从库会创建一个专门的 I/O 线程连接主库的 log dump 线程来接收主库的 binlog 日志再把 binlog 信息写入 relay log 的中继日志里再返回给主库“复制成功”的响应。从库会创建一个用于回放 binlog 的线程去读 relay log 中继日志然后回放 binlog 更新存储引擎中的数据最终实现主从的数据一致性。 从服务器的数量是不是越多越好这样分担下来的流量不就更小每个数据库的压力更小吗 不是的 从服务器数量增加对于主服务器来说IO连接的数量越多对于每一个从服务器的连接主服务器都需要创建一个log dump线程来专门负责与这个从服务器的请求。从服务器的数量越多对主服务器的资源消耗越多同时还要受限于主库的网络带宽。 在实际使用中一般遵循一主一副多从的设计也就是一个主服务器一个备用的主服务器在主服务器崩溃后担任主服务器2-3个从服务器 巨人的肩膀 小林Coding——MySQL日志《MySQL是怎么运行的》