The as-router Executable

The as-router executable provides the routing of transactions and space PUT and TAKE operations from the primary metaspace to the DR (disaster recovery) metaspace.

Multiple as-routers can be run on each site. Operations to be handled by as-routers are distributed to the as-routers in a round-robin fashion on both the primary and DR sites. Typically, you would run the same number of as-routers on each site. The idea is to run enough as-routers so as to keep the number of operations waiting to be sent to the DR site to a minimum. The number of operations waiting to be sent to the DR site can be monitored using the as-admin command show local site. The Pending route actions field indicates the number of operations in the internal space that are waiting to be sent to the DR site.

Operational Flow

The following is an example of the flow of a put operation when cross-site replication is used.

On the primary site, a client initiates the PUT operation of some data into a space. After the data is put and replicated into the appropriate space on the primary site, the PUT operation is stored into an internal routing space on the primary site and the client is unblocked. The PUT of data into the internal routing space triggers an as-router to pick up and asynchronously send the operation to the DR site. When the DR site receives the cross-site message, it sends an acknowledgment back to the primary site which then causes the primary site to remove the operation from the internal routing space. Back on the DR site, the operation is directed to an as-router which then performs the operation on the DR site.

This same basic flow is used for take operations and transactions. In the case of transactions, the entire transaction is stored to the internal routing space after the transaction has been committed on the primary site. Even though the transaction may contain multiple operations, you only see one entry for the entire transaction stored in the internal routing space.

Transmission Errors

Each operation put into the internal routing space is assigned a sequential log number. If a transmission error occurs while sending an operation to the DR site, the operation, and its log number, is put back into the internal routing space for resending. The sequential log number of an operation is used on the DR site to ensure that an operation with a smaller log number is not processed if an operation on the same key was already processed and the previously processed operation had a larger log number.

Seeding the Internal Routing Space

as-routers run as leech clients of the metaspace and do not seed any user spaces or the internal routing space. The C and Java as-agents, by default seed the internal routing space. If you are using your own custom built applications to seed your user spaces, those applications must be updated to also seed the internal routing space used for cross-site replication. See the section Starting a Custom Java Application as the First Metaspace Member for more information on how to configure your applications to seed the internal routing space.