You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: Chapter4_11.md
+6-6Lines changed: 6 additions & 6 deletions
Original file line number
Diff line number
Diff line change
@@ -26,14 +26,14 @@ MySQL asynchronous replication, semisynchronous replication, and Group Replicati
26
26
27
27
In a Group Replication multi-primary architecture, although transactions can be executed on any node, there are several known shortcomings:
28
28
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.
32
32
33
33
According to user feedback, users often utilize Group Replication multi-primary in the following ways:
34
34
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.
37
37
38
38
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.
39
39
@@ -67,7 +67,7 @@ The tests indicate that the scalability of the Group Replication multi-primary a
67
67
68
68
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.
69
69
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.
Copy file name to clipboardExpand all lines: Chapter4_12.md
+1-1Lines changed: 1 addition & 1 deletion
Original file line number
Diff line number
Diff line change
@@ -26,7 +26,7 @@ The most efficient testing method is to utilize real online traffic for evaluati
26
26
27
27
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].
28
28
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.
30
30
31
31
### 4.12.5 Is Testing About Discovering Problems or Verifying Them?
0 commit comments