diff --git a/Database.md b/Database.md index 3555872..cd1ad87 100644 --- a/Database.md +++ b/Database.md @@ -2401,54 +2401,18 @@ select * from t where k1=1 and k3=3; # MySQL日志 -**生产优化** - -- 在生产上，建议 innodb_flush_log_at_trx_commit 设置成 1，可以让每次事务的 redo log 都持久化到磁盘上。保证异常重启后，redo log 不丢失 -- 建议 sync_binlog 设置成 1，可以让每次事务的 binlog 都持久化到磁盘上。保证异常重启后，binlog 不丢失 - - - -**IO性能优化** - -- `binlog_group_commit_sync_delay`：表示延迟多少微秒后，再执行 `fsync` -- `binlog_group_commit_sync_no_delay_count`：表示累计多少次后，在调用 `fsync` - - - -当 `MySQL` 出现了 `IO` 的性能问题，可以考虑下面的优化策略： - -- 设置 `binlog_group_commit_sync_delay` 和 `binlog_group_commit_sync_no_delay_count`。可以使用故意等待来减少，`binlog` 的写盘次数，没有数据丢失的风险，但是会有客户端响应变慢的风险 -- 设置 `sync_binlog` 设置为 `100~1000` 之间的某个值。这样做存在的风险是可能造成 `binlog` 丢失 -- 设置 `innodb_flush_log_at_trx_commit = 2`，可能会丢数据 - - - -**重做日志（redo log）、二进制日志（bin log）、回滚日志（undo log）、错误日志（error log）、慢查询日志（slow query log）、一般查询日志（general log）、中继日志（relay log）**。 - - +**重做日志（redo log）、二进制日志（bin log）、回滚日志（undo log）、错误日志（error log）、慢查询日志（slow query log）、一般查询日志（general log）、中继日志（relay log）。** ## 二进制日志(bin log) -`binlog` 用于记录数据库执行的写入性操作(不包括查询)信息，以二进制的形式保存在磁盘中。`binlog` 是 `mysql`的逻辑日志，并且由 `Server` 层进行记录，使用任何存储引擎的 `mysql` 数据库都会记录 `binlog` 日志。 - -- **逻辑日志**：可以简单理解为记录的就是sql语句 。 -- **物理日志**：`mysql` 数据最终是保存在数据页中的，物理日志记录的就是数据页变更 。 +`binlog` 用于记录数据库执行的写入性操作(不包括查询)信息，以二进制的形式保存在磁盘中。`binlog` 是 `mysql`的逻辑日志(即SQL语句)，并且由 `Server` 层进行记录，使用任何存储引擎的 `mysql` 数据库都会记录 `binlog` 日志。`binlog` 是通过追加的方式进行写入的，可以通过`max_binlog_size` 参数设置每个 `binlog`文件的大小，当文件大小达到给定值之后，会生成新的文件来保存日志。 -`binlog` 是通过追加的方式进行写入的，可以通过`max_binlog_size` 参数设置每个 `binlog`文件的大小，当文件大小达到给定值之后，会生成新的文件来保存日志。 -### 作用 -- 用于复制，在主从复制中，从库利用主库上的binlog进行重播，实现主从同步 -- 用于数据库的基于时间点的还原 +**作用** - - -### 使用场景 - -在实际应用中， `binlog` 的主要使用场景有两个，分别是 **主从复制** 和 **数据恢复** 。 - -- **主从复制** ：在 `Master` 端开启 `binlog` ，然后将 `binlog`发送到各个 `Slave` 端， `Slave` 端重放 `binlog` 从而达到主从数据一致 -- **数据恢复** ：通过使用 `mysqlbinlog` 工具来恢复数据 +- **主从复制**：在主从复制中，从库利用主库上的binlog进行重播，实现主从同步 +- **数据恢复**：通过使用mysqlbinlog`工具来实现数据库基于时间点的还原 @@ -2456,9 +2420,9 @@ select * from t where k1=1 and k3=3; 对于 `InnoDB` 存储引擎而言，只有在事务提交时才会记录`biglog` ，此时记录还在内存中，那么 `biglog`是什么时候刷到磁盘中的呢？`mysql` 通过 `sync_binlog` 参数控制 `biglog` 的刷盘时机，取值范围是 `0-N`： -- `sync_binlog=0`：不去强制要求，由系统自行判断何时写入磁盘； -- `sync_binlog=1`：每次 `commit` 的时候都要将 `binlog` 写入磁盘； -- `sync_binlog=N(N>1)`：每N个事务，才会将 `binlog` 写入磁盘。 +- `sync_binlog=0`：不去强制要求，由系统自行判断何时写入磁盘 +- `sync_binlog=1`：每次 `commit` 的时候都要将 `binlog` 写入磁盘 +- `sync_binlog=N(N>1)`：每N个事务，才会将 `binlog` 写入磁盘 从上面可以看出， `sync_binlog` 最安全的是设置是 `1` ，这也是`MySQL 5.7.7`之后版本的默认值。但是设置一个大一些的值可以提升数据库性能，因此实际情况下也可以将值适当调大，牺牲一定的一致性来获取更好的性能。 @@ -2466,39 +2430,47 @@ select * from t where k1=1 and k3=3; ### 日志格式 -`binlog` 日志有三种格式，分别为 `STATMENT` 、 `ROW` 和 `MIXED`。 +`binlog` 日志有三种格式，日志格式通过 `binlog-format` 指定。在 `MySQL 5.7.7` 之前，默认的格式是 `STATEMENT` ， `MySQL 5.7.7` 之后，默认值是 `ROW`。 -在 `MySQL 5.7.7` 之前，默认的格式是 `STATEMENT` ， `MySQL 5.7.7` 之后，默认值是 `ROW`。日志格式通过 `binlog-format` 指定。 - -- `STATMENT`：基于`SQL`语句的复制( `statement-based replication, SBR` )，每一条会修改数据的sql语句会记录到`binlog` 中 -- - 优点：不需要记录每一行的变化，减少了 binlog 日志量，节约了 IO , 从而提高了性能； - - 缺点：在某些情况下会导致主从数据不一致，比如执行sysdate() 、 slepp() 等 。 -- `ROW`：基于行的复制(`row-based replication, RBR` )，不记录每条sql语句的上下文信息，仅需记录哪条数据被修改了 。 - - 优点：不会出现某些特定情况下的存储过程、或function、或trigger的调用和触发无法被正确复制的问题 ； - - 缺点：会产生大量的日志，尤其是` alter table ` 的时候会让日志暴涨 +- `STATMENT`：基于`SQL`语句复制(`statement-based replication, SBR`)，每一条会修改数据的sql语句会记录到`binlog`中 + - **优点**：不需要记录每一行的变化，减少了binlog日志量，节约了IO，从而提高了性能 + - **缺点**：在某些情况下会导致主从数据不一致，比如执行sysdate()、slepp() 等 +- `ROW`：基于行复制(`row-based replication, RBR` )，不记录每条sql语句的上下文信息，仅需记录哪条数据被修改了。 + - **优点**：不会出现某些特定情况下的存储过程、或function、或trigger的调用和触发无法被正确复制的问题 + - **缺点**：会产生大量的日志，尤其是` alter table ` 的时候会让日志暴涨 - `MIXED`：基于`STATMENT` 和 `ROW` 两种模式的混合复制(`mixed-based replication, MBR` )，一般的复制使用`STATEMENT` 模式保存 `binlog` ，对于 `STATEMENT` 模式无法复制的操作使用 `ROW` 模式保存 `binlog` ## 重做日志(redo log) -重做日志（redo log）是InnoDB引擎层的日志，用来记录事务操作引起数据的变化，记录的是数据页的物理修改。 +**重做日志是InnoDB引擎层日志，用来记录事务操作引起数据变化，记录的是数据页的物理修改。**包括两部分： + +- **内存中的日志缓冲(redo log buffer)** +- **磁盘上的日志文件(redo logfile)** + +MySQL 每执行一条 DML 语句，先将记录写入 redo log buffer，后续某个时间点再一次性将多个操作记录写到 redo log file，种先写日志再写磁盘的技术就是 WAL(Write-Ahead Logging) 技术。之后MySQL会在合适的时候将操作记录 flush 到磁盘上面，flush 的条件可能是系统比较空闲，或 redo log 空间不足时。redo log 文件的大小是固定的，如可以是由4个1GB文件组成的集合。 + -在MySQL里，如果我们要执行一条更新语句。执行完成之后，数据不会立马写入磁盘，因为这样对磁盘IO的开销比较大。MySQL里面有一种叫做WAL（Write-Ahead Logging），就是先写日志再写磁盘。就是当有一条记录需要更新的时候，InnoDB 会先写redo log 里面，并更新内存，这个时候更新的操作就算完成了。之后，MySQL会在合适的时候将操作记录 flush 到磁盘上面。当然 flush 的条件可能是系统比较空闲，或者是 redo log 空间不足时。redo log 文件的大小是固定的，比如可以是由4个1GB文件组成的集合。 -### 作用 +**WAL(Write-Ahead Logging)** -确保事务的持久性。防止在发生故障的时间点，尚有脏页未写入磁盘，在重启mysql服务的时候，根据redo log进行重做，从而达到事务的持久性这一特性。 + + +**作用** + +- **确保事务的持久性** +- **防止发生故障时，尚有脏页未写入磁盘**。在重启mysql服务时，根据redo log进行重做，从而达到事务的持久性特性 ### 写入流程 -为了控制 redo log 的写入策略，innodb_flush_log_at_trx_commit 会有下面 3 中取值： +为了控制 `redo log` 的写入策略，`innodb_flush_log_at_trx_commit` 会有下面 3 中取值： -- **0：每次提交事务只写在 redo log buffer 中** -- **1：每次提交事务持久化到磁盘** -- **2：每次提交事务写到 文件系统的 page cache 中** +- `0`：**每次提交事务只写在 `redo log buffer` 中** +- `1`：**每次提交事务持久化到磁盘** +- `2`：**每次提交事务写到 文件系统的 `page cache` 中** @@ -2516,11 +2488,20 @@ redo log 实际的触发 fsync 操作写盘包含以下几个场景： ## 回滚日志(undo log) -### 作用 +undo log记录的是数据修改之前的数据。主要用于**回滚，**MySQL数据库事务的**原子性**就是通过 undo log实现的。 + +undo log主要存储的是数据的逻辑变化日志，比如我们要 insert 一条数据，那么 undo log 就会生成一条对应的 delete 日志。所以当需要回滚时，只需要利用undo log 就可以恢复都修改前的数据。 + +undo log另一个作用是用来实现**多版本并发控制 MVCC。** + +undo记录中包含了记录更改前的镜像，如果更改数据的事务未提交，对于隔离级别大于等于 read commit的事务而言，不应该返回更改后的数据，而应该返回更改前的数据。 + -保证数据的原子性，保存了事务发生之前的数据的一个版本，可以用于回滚，同时可以提供多版本并发控制下的读（MVCC），也即非锁定读。 +**作用** +- 保证数据的原子性。保存了事务发生之前的数据的一个版本，可以用于回滚 +- 可以提供多版本并发控制下的读（MVCC），也即非锁定读