MXS-3892: Document the change in behavior
It is worth documenting this change as the amount of queries done by MaxScale is likely to decrease by a significant amount. This change can also have a negative effect on the worst-case delay of the database mapping but this isn't really a practical problem.
This commit is contained in:
		@ -51,6 +51,21 @@ db1.t2   |MyServer1    |
 | 
			
		||||
db2.t1   |MyServer2    |
 | 
			
		||||
```
 | 
			
		||||
 | 
			
		||||
### Database Mapping
 | 
			
		||||
 | 
			
		||||
The schemarouter maps each of the servers to know where each database and table
 | 
			
		||||
is located. As each user has access to a different set of tables and databases,
 | 
			
		||||
the result is unique to the username and the set of servers that the service
 | 
			
		||||
uses. These results are cached by the schemarouter. The lifetime of the cached
 | 
			
		||||
result is controlled by the `refresh_interval` parameter.
 | 
			
		||||
 | 
			
		||||
When a server needs to be mapped, the schemarouter will route a query to each of
 | 
			
		||||
the servers using the client's credentials. While this query is being executed,
 | 
			
		||||
all other sessions that would otherwise share the cached result will wait for
 | 
			
		||||
the update to complete. This waiting functionality was added in MaxScale 2.4.19,
 | 
			
		||||
older versions did not wait for existing updates to finish and would perform
 | 
			
		||||
parallel database mapping queries.
 | 
			
		||||
 | 
			
		||||
## Configuration
 | 
			
		||||
 | 
			
		||||
Here is an example configuration of the schemarouter:
 | 
			
		||||
 | 
			
		||||
		Reference in New Issue
	
	Block a user