Skip to content

Commit ab9e1b1

Browse files
committed
Further improve the documentation.
1 parent 7be5b9f commit ab9e1b1

File tree

2 files changed

+7
-7
lines changed

2 files changed

+7
-7
lines changed

Chapter4_11.md

Lines changed: 6 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -26,14 +26,14 @@ MySQL asynchronous replication, semisynchronous replication, and Group Replicati
2626

2727
In a Group Replication multi-primary architecture, although transactions can be executed on any node, there are several known shortcomings:
2828

29-
1. Lack of a global transaction manager.
30-
2. Limited transaction isolation levels.
31-
3. Potential for traffic skew under heavy write pressure.
29+
1. Lack of a global transaction manager.
30+
2. Limited transaction isolation levels.
31+
3. Potential for traffic skew under heavy write pressure.
3232

3333
According to user feedback, users often utilize Group Replication multi-primary in the following ways:
3434

35-
1. They require that transactions between nodes do not conflict with each other.
36-
2. Despite being multi-primary, transactions are executed on only one node to avoid the overhead of switching primaries.
35+
1. They require that transactions between nodes do not conflict with each other.
36+
2. Despite being multi-primary, transactions are executed on only one node to avoid the overhead of switching primaries.
3737

3838
The following figure shows SysBench's read-write performance over time, where each node accesses the same database and handles both read and write tasks.
3939

@@ -67,7 +67,7 @@ The tests indicate that the scalability of the Group Replication multi-primary a
6767

6868
Based on event-driven architecture, common in web servers like Nginx, Percona's thread pool can be seen as a rough approximation of event-driven systems. However, event-driven architecture isn't free—it incurs overhead from system calls, and this additional overhead constitutes the cost of using a thread pool.
6969

70-
MySQL's underlying Paxos communication can also be viewed as asynchronous event-driven. This communication operates in a single-threaded mode, requiring the avoidance of any synchronous communication processes. Unfortunately, MySQL has gradually violated these principles in its ongoing feature expansion, leading to throughput problems in certain scenarios due to prolonged synchronous processes dropping to zero. For problems related to Group Replication synchronization, refer to the highlighted code snippet below.
70+
MySQL's underlying Paxos communication can also be viewed as asynchronous event-driven. This communication operates in a single-threaded mode, requiring the avoidance of any synchronous communication processes. Unfortunately, MySQL has gradually violated these principles in its ongoing feature expansion, leading to throughput problems in certain scenarios due to prolonged synchronous processes dropping to zero. For problems related to Group Replication synchronization, see the code snippet below.
7171

7272
```c++
7373
/* Try to connect to another node */

Chapter4_12.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -26,7 +26,7 @@ The most efficient testing method is to utilize real online traffic for evaluati
2626

2727
In Oracle, Database Replay enables testing a system with real production workloads, helping identify potential problems before implementing changes on the production system. Any workload period can be captured with little overhead and used to drive a test system, maintaining the concurrency and load characteristics of the real workload. Maintaining these characteristics is crucial, as current testing solutions often lack synchronization based on data dependencies. Without proper synchronization, the workload does not perform as required, leading to poor coverage and inadequate load, leaving many problems undetected. Database Replay's data-based synchronization makes testing realistic and helps discover potential problems [34].
2828

29-
In MySQL, a common strategy involves taking a MySQL secondary instance offline for testing, configuring the necessary cluster, and replicating online MySQL requests to this new testing primary. The closer the testing primary resembles the production environment, the more accurate the test results. There are various methods to replicate online MySQL requests. This book recommends the open-source tool TCPCopy [60]. By using TCPCopy, many online problems have been successfully mitigated, laying a solid foundation for MySQL proxy enhancements [61]. For testing a MySQL cluster, replicating online requests to the testing system using TCPCopy allows us to evaluate whether the modifications achieve the expected outcomes, such as performance improvements, and robustness.
29+
In MySQL, a common strategy involves taking a MySQL secondary instance offline for testing, configuring the necessary cluster, and replicating online MySQL requests to this new testing primary. The closer the testing primary resembles the production environment, the more accurate the test results. There are various methods to replicate online MySQL requests. This book recommends the open-source tool TCPCopy [60]. By using TCPCopy, many online problems have been successfully effectively resolved, laying a solid foundation for MySQL proxy enhancements [61]. For testing a MySQL cluster, replicating online requests to the testing system using TCPCopy allows us to evaluate whether the modifications achieve the expected outcomes, such as performance improvements, and robustness.
3030

3131
### 4.12.5 Is Testing About Discovering Problems or Verifying Them?
3232

0 commit comments

Comments
 (0)