Save Mon Nov 14 11:23:00 PM CST 2022

Author: littleneko

Diff for: MySQL/MySQL semi-sync.md

@@ -0,0 +1,59 @@
+# MySQL Asynchronous Replication
+
+<img src="https://littleneko.oss-cn-beijing.aliyuncs.com/img/image-20221114231007636.png" alt="image-20221114231007636" style="zoom: 33%;" />
+
+# MySQL Semisynchronous Replication
+MySQL的 semi-sync 如下图所示，Master 先写 binlog，Slave 收到 Master 的 binlog 并且写 relay log 之后给Master 回复 ACK，此时 Master 才 commit 事物。MySQL 的 semi-sync 实际上保证的是事物提交之前已经至少有一个 Slave 接收到该数据的 binlog 了。
+
+<img src="https://littleneko.oss-cn-beijing.aliyuncs.com/img/image-20221114231151677.png" alt="image-20221114231151677" style="zoom: 33%;" />
+
+## AFTER SYNC 和 AFTER COMMIT
+上图中可以看到最后一个步骤是 commit，具体这个 COMMIT 是指什么？MySQL 的事物提交其实是 binlog 和 redolog 两阶段提交，这里的 commit 是指两阶段的哪一步？
+
+实际上根据 _rpl_semi_sync_master_wait_point_ 参数设置的不同，有两种情况。
+
+- `AFTER_SYNC` (the default): The master writes each transaction to its binary log and the slave, and syncs the binary log to disk. The master waits for slave acknowledgment of transaction receipt after the sync. Upon receiving acknowledgment, the master commits the transaction to the storage engine and returns a result to the client, which then can proceed.
+- `AFTER_COMMIT`: The master writes each transaction to its binary log and the slave, syncs the binary log, and commits the transaction to the storage engine. The master waits for slave acknowledgment of transaction receipt after the commit. Upon receiving acknowledgment, the master returns a result to the client, which then can proceed.
+
+**AFTER SYNC **示意图
+
+![image-20221114231253829](https://littleneko.oss-cn-beijing.aliyuncs.com/img/image-20221114231253829.png)
+
+**AFTER COMMIT **示意图：
+
+![image-20221114231420578](https://littleneko.oss-cn-beijing.aliyuncs.com/img/image-20221114231420578.png)
+
+所以这两中方式的区别在于 engine 提交的时机：
+
+- `AFTER_SYNC` ：master 收到 binlog ack -> ==engine commit== -> 返回客户端成功
+- `AFTER_COMMIT` ：==engine commit== -> master 收到 binlog ack -> 返回客户端成功
+
+一句话总结：==_**after_commit 在主机事务提交后将日志传送到从机，after_sync 是先传再提交**_==
+
+
+The replication characteristics of these settings differ as follows:
+
+- With `AFTER_SYNC`, ==all clients see the committed transaction at the same time==: After it has been acknowledged by the slave and committed to the storage engine on the master. Thus, all clients see the same data on the master.
+
+  In the event of master failure, all transactions committed on the master have been replicated to the slave (saved to its relay log). A crash of the master and failover to the slave is lossless because the slave is up to date.
+
+- With `AFTER_COMMIT`, ==the client issuing the transaction gets a return status only after the server commits to the storage engine and receives slave acknowledgment==. _After the commit and before slave acknowledgment, other clients can see the committed transaction before the committing client._
+If something goes wrong such that the slave does not process the transaction, then in the event of a master crash and failover to the slave, it is possible that such clients will see a loss of data relative to what they saw on the master.
+
+==`AFTER_COMMIT` 下，因为 engine 先 commit 了，事务持有锁的时间更短，但是如果这时主库 crash，从切换为主，可能导致在从上读不到数据。==
+
+=="Engine Commit" makes data permanent and release locks on the data. So other sessions can reach the data since then==, even if the session is still waiting for the acknowledgement. It will cause ==phantom read== if master crashes and slave takes work over.
+
+![image-20221114231510230](/home/littleneko/.config/Typora/typora-user-images/image-20221114231510230.png)
+
+# Links
+
+1. [https://dev.mysql.com/doc/refman/5.7/en/group-replication-primary-secondary-replication.html](https://dev.mysql.com/doc/refman/5.7/en/group-replication-primary-secondary-replication.html)
+2. [https://dev.mysql.com/doc/refman/5.7/en/replication-semisync.html](https://dev.mysql.com/doc/refman/5.7/en/replication-semisync.html)
+3. [http://my-replication-life.blogspot.com/2013/09/loss-less-semi-synchronous-replication.html](http://my-replication-life.blogspot.com/2013/09/loss-less-semi-synchronous-replication.html)
+4. [http://my-replication-life.blogspot.com/2013/12/enforced-semi-synchronous-replication.html](http://my-replication-life.blogspot.com/2013/12/enforced-semi-synchronous-replication.html)
+5. [http://my-replication-life.blogspot.com/2014/03/faster-semisync-replication.html](http://my-replication-life.blogspot.com/2014/03/faster-semisync-replication.html)
+
+## 扩展阅读
+
+- P8 级面试难题，after_sync vs after_commit，哪个性能更好？：[https://mp.weixin.qq.com/s/fvvEn6nSYzQs9NCa1eCOIQ](https://mp.weixin.qq.com/s/fvvEn6nSYzQs9NCa1eCOIQ)

Diff for: README.md

@@ -2,6 +2,8 @@
 Notes
 
 ## 目录
+1. **MySQL**
+    1. [MySQL semi-sync](./MySQL/MySQL%20semi-sync.md)
 1. **其他**
     1. [OpenWrt](./%E5%85%B6%E4%BB%96/OpenWrt.md)
 1. **学习笔记**

Diff for: 读书笔记/CMU 15-445:645 Database Systems (Fall 2021)/Lecture #18: Multi-Version Concurrency Control.md

@@ -59,7 +59,7 @@ T~2~ 不能写 A，因为 T~1~ 写了 A 并且还未提交，存在 Write-Write
 
 > **Tips**:
 >
-> * 这个例子中的调度并不是 **serializable** 的，原因是最后结果并不等价于任何一个串行化调度，这个例子是符合 **Snapshot Isolation** 的。
+> * 这个例子中的调度并不是 **serializable** 的，原因是最后结果并不等价于任何一个串行化调度，但是这个例子是符合 **Snapshot Isolation** 的。
 > * 如果是在 **serializable** 隔离级别下，上面的 T~2~ 将不会 Commit 成功。
 > * 这个例子实际上是有==**丢失更新**==（**Lost Update**）发生的，实际上很多快照隔离的数据库都会做冲突检测，避免更新丢失的情况，因此一般当人们讲 “快照隔离” 时都是默认避免了更新丢失的情况的。
 

Diff for: 读书笔记/CMU 15-445:645 Database Systems (Fall 2021)/Lecture #19: Logging Schemes.md

@@ -77,7 +77,7 @@ The easiest buffer pool management policy to implement is called *NO-STEAL + FOR
 
 A limitation of NO STEAL + FORCE is that all of the data that ==a transaction needs to modify must fit on memory==. Otherwise, that transaction cannot execute because the DBMS is not allowed to write out dirty pages to disk before the transaction commits.
 
-![image-20220316000216064](https://littleneko.oss-cn-beijing.aliyuncs.com/img/image-20220316000216064.png)
+<img src="https://littleneko.oss-cn-beijing.aliyuncs.com/img/image-20220316000216064.png" alt="image-20220316000216064" style="zoom: 33%;" />
 
 #  Shadow Paging
 
@@ -88,7 +88,7 @@ The DBMS maintains two separate copies of the database:
 
 ==Updates are only made in the shadow copy==. When a transaction commits, the shadow is atomically switched to become the new master. This is an example of a NO-STEAL + FORCE system. A high-level example of shadow paging is shown in Figure 2.
 
-![image-20220316000431148](https://littleneko.oss-cn-beijing.aliyuncs.com/img/image-20220316000431148.png)
+<img src="https://littleneko.oss-cn-beijing.aliyuncs.com/img/image-20220316000431148.png" alt="image-20220316000431148" style="zoom:33%;" />
 
 ## Implementation
 
@@ -127,7 +127,7 @@ When a transaction modifies a page, the DBMS copies the original page to a separ
 
 With *write-ahead logging*, the DBMS records all the changes made to the database in a log file (on stable storage) before the change is made to a disk page. The log contains sufficient information to perform the necessary undo and redo actions to restore the database after a crash. ==The DBMS must write to disk the log file records that correspond to changes made to a database object before it can flush that object to disk==. An example of WAL is shown in Figure 3. WAL is an example of a ==STEAL + NO-FORCE== system.
 
-![image-20220316002124274](https://littleneko.oss-cn-beijing.aliyuncs.com/img/image-20220316002124274.png)
+<img src="https://littleneko.oss-cn-beijing.aliyuncs.com/img/image-20220316002124274.png" alt="image-20220316002124274" style="zoom: 33%;" />
 
 In shadow paging, the DBMS was required to perform writes to random non-contiguous pages on disk. Write-ahead logging allows the DBMS to convert random writes into ==sequential writes== to optimize performance. Thus, almost every DBMS uses write-ahead logging (WAL) because it has the fastest runtime performance. But the DBMS’s recovery time with WAL is slower than shadow paging because it has to replay the log.
 
@@ -168,7 +168,7 @@ The contents of a log record can vary based on the implementation.
 * Requires less data written in each log record than physical logging because each record can update multiple tuples over multiple pages. However, it is difficult to implement recovery with logical logging when there are concurrent transactions in a non-deterministic concurrency control scheme. Additionally recovery takes longer because you must re-execute every transaction.
 * Example: The UPDATE, DELETE, and INSERT queries invoked by a transaction.
 
-Physiological Logging:
+**Physiological Logging**:
 
 * Hybrid approach where log records target a single page but do not specify data organization of the page. That is, identify tuples based on a slot number in the page without specifying exactly where in the page the change is located. Therefore the DBMS can reorganize pages after a log record has been written to disk.
 * Most common approach used in DBMSs.

Diff for: 读书笔记/CMU 15-445:645 Database Systems (Fall 2021)/Lecture #21: Database Crash Recovery.md

@@ -17,7 +17,7 @@ There are three key concepts in the ARIES recovery protocol:
 
 Write-ahead log records extend the DBMS’s log record format to include a globally unique *log sequence number* (==**LSN**==). A high level diagram of how log records with LSN’s are written is shown in Figure 1.
 
-![image-20220316230013409](https://littleneko.oss-cn-beijing.aliyuncs.com/img/image-20220316230013409.png)
+<img src="https://littleneko.oss-cn-beijing.aliyuncs.com/img/image-20220316230013409.png" alt="image-20220316230013409"  />
 
 All log records have an LSN. The ==**pageLSN**== is updated every time a transaction modifies a record in the page. The ==**flushedLSN**== in memory is updated every time the DBMS writes out the WAL buffer to disk.