Chapter 1 General Information

Connection routing (also called standalone routing to distinguish it from Fabric integrated connection routing - see below) is the ability to permit the redirection of connections sent to the router to an available MySQL server. Connection routing is simply the redirection of the MySQL packets in their entirety without inspection.

This means you can setup your application to connect to the router and should the current MySQL server fail, retry the connection and the router will select a new MySQL server to redirect the connection.

We call this simple redirect connection routing because it requires the application to retry the connection. That is, if a connection from MySQL Router to the MySQL server is interrupted (such as, the server goes offline), the application will encounter a connection failure. However, a new connection attempt will trigger the router to find another server to connect.

We specify the servers we want to use in a routing strategy in the configuration file. For example, the following section tells the router to listen for connections on port 7002 of the localhost, and then redirect those connections to any of the servers in the list named by the destinations option, including servers running on the localhost listening on ports 3306, 3307, and 3308. Finally, we use the mode option to tell the router to allow both readers and writers. For more information about the available modes, see the section entitled, Configuration File Setup below.

[routing:simple_redirect]
bind_port = 7002
mode = read-write
destinations = localhost:3306,localhost:3307,localhost:3308
      

Notice that the section is entitled, routing:simple_redirect. The first part, routing is called the section name and is used internally to determine which plugin to load. The last part is an option section key (name) you can optionally provide should you want to set up more than one routing strategy.

When a server is no longer reachable, the router moves to the next one in the list. When the list is exhausted, the router halts redirecting.

Using MySQL Fabric with the router is another form of connection routing (also called Fabric integration) but instead of configuring the destinations manually, the list is provided by MySQL Fabric. Recall Fabric allows you to manage a farm of MySQL servers by grouping the servers in high availability groups for redundancy (allowing for automatic failover) and for easier management. Thus, Fabric maintains a list of the servers in the farm including their roles and how each is configure. Fabric can supply this list to the router via the Fabric cache.

With the router, we can use Fabric to supply the routes for connections to an appropriated MySQL Server based on information provided in Fabric via the Fabric cache. Essentially, we connect the router to Fabric and get the high availability feature for free.

Fortunately, this is not complicated to set up. All you need is another routing strategy like we saw with simple redirect connection routing. In this case, we set up a new section in the configuration file as demonstrated below.

We set up the router to listen on port 19906 on the localhost with a mode set to read-only, which is typical in an application written to use Fabric (or replication in general). We need two sections in the configuration file like so:

[fabric_cache:webfarm]
address = fabric.example.com
user = fabricuser

[routing:webfarm]
bind_port = 19906
destinations = fabric+cache://webfarm/group/homepage/
mode = read-only

The first section sets the address and user for the Fabric connection. The second sets the routing strategy.

Notice here we set the destinations option to point to the Fabric cache via a URI. When you set up a Fabric integration like this, you will be prompted for the Fabric password when you start the router.

We used the section name "fabric_cache" to indicate this is a fabric integrated connection routing strategy. Finally, notice we provide the Fabric user account using the user option.

One of the interesting features of MySQL Router is not something the average user will see - it is under the hood. More specifically, the router is designed to permit the use of plugins to enable features. The plugin technology is called MySQL Harness.

MySQL Harness provides a number of advantages for the router including the ability to load new functionality without having to alter the original mysqlrouter application, which means faster development times for new features and the possibility of selectively loading features. The harness also provides logging, which enables developers to turn on a log of events without having to write any specialized logging code.

The features provided my MySQL Harness include the following:

While the harness feature set and usage may not be obvious initially, the long-term benefits of developing with a plugin-based design are well documented.

In its current form, the MySQL Router is best used alongside the application. That is, you should install the router on the same machines that hosts the application. While this is not a rule or requirement, it is the recommended practice.

Since the router is on the same machine as the application, this means you can write your application to monitor the mysqlrouter executable and restart it should you need to. For example, if the list of servers in the destinations option is exhausted, you can restart the router with a new destinations list or restart the router to retry the servers in the list.

The following graphic represents how you could employ the router with your application:

Figure 1.2 Positioning MySQL Router

You can run several instances of the router throughout your network. You do not need to isolate the router to a single machine or even a single instance. This is because there is nothing in the router to give it affinity for any one server or machine. It is essentially agnostic in that manner.

Developing applications for use with the router does not require any special application library or interface. Aside from managing the MySQL Router instance, your application can be written as if the router were not there.

The only difference you may want to do is how you use connections to the MySQL server. If your application uses a single connection made at startup and does not test for connection errors, you may need to change that behavior.

This is because the router merely redirects connections when the connection is attempted. The router does not read packets or perform any form of analysis. Thus, if a server goes down, the router will return a connection error to the host application.

Thus, the application should be written to test for connection errors and, if encountered, retry the connection. If this technique or one similar is employed in your application, using MySQL Router will be seamless.

The following gives you a better idea of why you may want to use the router, and a look into how it is used from an application.

cnx = mysql.connector.connect(host='router.example.com', port=8500, user='scott', password='tiger')
cur = cnx.cursor()
cnx.execute("SELECT ...")