Merge branch '23.02' into 23.08

mariadb-joecotellese · Jun 13, 2024 · e8da365 · e8da365
2 parents 107b973 + 6ddad25
commit e8da365
Show file tree

Hide file tree

Showing 9 changed files with 56 additions and 56 deletions.
diff --git a/Documentation/Getting-Started/Configuration-Guide.md b/Documentation/Getting-Started/Configuration-Guide.md
@@ -3647,7 +3647,7 @@ API. **Only do this if you know what you are doing.**
 
 ## Filter Modules
 
-![image alt text](images/image_10.png)
+![Processing pipeline with two filters](images/filter_example.png)
 
 Filters provide a means to manipulate or process requests as they pass through
 MariaDB MaxScale between the client side protocol and the query router. A full

diff --git a/...ation/Getting-Started/images/image_10.png → ...Getting-Started/images/filter_example.png b/...ation/Getting-Started/images/image_10.png → ...Getting-Started/images/filter_example.png
diff --git a/Documentation/Getting-Started/images/getting_started.png b/Documentation/Getting-Started/images/getting_started.png
diff --git a/Documentation/Getting-Started/images/getting_started2.png b/Documentation/Getting-Started/images/getting_started2.png
diff --git a/Documentation/Getting-Started/images/image_0.png b/Documentation/Getting-Started/images/image_0.png
diff --git a/Documentation/Getting-Started/images/image_1.png b/Documentation/Getting-Started/images/image_1.png
diff --git a/Documentation/Getting-Started/images/image_11.png b/Documentation/Getting-Started/images/image_11.png
diff --git a/Documentation/Monitors/MariaDB-Monitor.md b/Documentation/Monitors/MariaDB-Monitor.md
@@ -1099,7 +1099,7 @@ are running when three are needed for majority. Although both MaxScales see both
 running servers, neither is certain they have majority and the cluster stays in
 read-only mode. If the primary server is down, no failover is performed either.
 
-<img src="images/coop_lock_no_majority.png" alt="Neither MaxScale can claim majority if too many servers go down when using majority_of_all"/>
+![Neither MaxScale can claim majority if too many servers go down when using majority_of_all](images/coop_lock_no_majority.png)
 
 Setting `cooperative_monitoring_locks=majority_of_running` changes the way
 *n_servers* is calculated. Instead of using the total number of servers, only
@@ -1115,7 +1115,7 @@ Both MaxScales claim two locks out of two available and assume that they have
 lock majority. Both MaxScales may then promote their own primaries and route
 writes to different servers.
 
-<img src="images/coop_lock_split_brain.png" alt="Both MaxScales claim majority in split-brain situation when using majority_of_running"/>
+![Both MaxScales claim majority in split-brain situation when using majority_of_running](images/coop_lock_split_brain.png)
 
 The recommended strategy depends on which failure scenario is more likely and/or
 more destructive. If it's unlikely that multiple servers are ever down
@@ -1140,7 +1140,7 @@ can be further decreased by configuring each monitor with a different
 
 The flowchart below illustrates the lock handling logic.
 
-<img src="images/coop_lock_flowchart.svg" alt="Cooperative monitoring lock decision flowchart" width="550"/>
+![Cooperative monitoring lock decision flowchart](images/coop_lock_flowchart.svg)
 
 ### Releasing locks
 

diff --git a/Documentation/Monitors/images/coop_lock_flowchart.svg b/Documentation/Monitors/images/coop_lock_flowchart.svg