Version Tokens •Client applications that access the servers to retrieve and update data, choosing servers according to the purposes assigned them. For example, a client should not send an update to a read-only server. •The management application performs server assignments and establishes version tokens on each server to reflect its assignment. The application caches this information to provide a central access point to it. •To improve performance, client applications obtain cache information from the management application, enabling them to avoid having to retrieve information about server assignments for each statement. Based on the type of statements it issues (for example, reads versus writes), a client selects an appropriate server and connects to it. •In addition, the client sends to the server its own client-specific version tokens to register the assignment it requires of the server. For each statement sent by the client to the server, the server compares its own token list with the client token list. If the server token list contains all tokens present in the client token list with the same values, there is a match and the server executes the statement. •The logic for those actions can be implemented in a connector that manages connections between clients and MySQL servers. Such a connector might handle mismatch error detection and statement resending itself, or it might pass the error to the application and leave it to the application to resend the statement. •The client can handle all version token registration, mismatch detection, and connection switching itself. 1100 Client applications register a list of version tokens they require the server to match by setting a system variable. Variable setting occurs on a client-specific basis, so different clients can register different Suppose that a management application communicates with a set of servers that are queried by clients to access employee and product databases (named  emp  and  prod , respectively). All servers are permitted to process data retrieval statements, but only some of them are permitted to make database updates. To handle this on a database-specific basis, the management application establishes a list of version tokens on each server. In the token list for a given server, token names represent database names and token values are  read  or  write  depending on whether the database must be used in read-only fashion or whether it can take reads and writes. When Version Tokens initializes on a given server, the server’s version token list is empty. Token list maintenance is performed by calling functions. The  VERSION_TOKEN_ADMIN  privilege (or the deprecated SUPER  privilege) is required to call any of the Version Token functions, so token list modification is expected to be done by a management or administrative application that has that privilege. The following example illustrates the preceding discussion in more concrete form. The client-side logic for detecting version token errors and selecting a new server can be implemented different ways: On the other hand, perhaps the management application has changed the server assignment and its version token list. In this case, the new server assignment may now be incompatible with the client requirements. A token mismatch between the server and client token lists occurs and the server returns an error in reply to the statement. This is an indication to the client to refresh its version token information from the management application cache, and to select a new server to communicate with. If at some point the management application needs to change a server assignment (for example, to change it from permitting writes to read only), it changes the server’s version token list and updates its cache. Version Tokens permit server access to be managed according to assignment without requiring clients to repeatedly query the servers about their assignments: