Overview

OceanBase Database Proxy (ODP) provides a wide range of intra-tenant routing modes. You can select a routing mode as needed. If you encounter any problems, you can view the routing process in ODP by using the routing diagnostics feature. For more information about the routing diagnostics feature, see Routing diagnostics.

ODP provides the following intra-tenant routing modes:

• IP address-based routing: In this mode, an OBServer node is specified by using the target_db_server parameter of ODP or by using a statement. ODP routes data read statements to the specified OBServer node. This routing mode has the highest priority. If an IP address is specified, ODP will ignore other routing modes. For more information, see IP address-based routing.

• Partitioned table-based routing for strong-consistency reads: In this mode, the partitioning key, partitioning key expression, or partition name is provided in a strong-consistency read statement to a partitioned table. ODP accurately routes the statement to the OBServer node of the leader of the partition where the data resides. For more information, see Partitioned table-based routing in strong-consistency reads.

• Global index table-based routing for strong-consistency reads: In this mode, the column value, value expression, or index partition name of the global index table is provided in a strong-consistency read statement to the primary table. ODP accurately routes the statement to the OBServer node of leader of the index partition where the data resides. For more information, see Global index table-based routing in strong-consistency reads.

• Replication table-based routing for strong-consistency reads: For a strong-consistency read statement to a replication table, ODP routes the statement to the OBServer node nearest to ODP. For more information, see Replication table-based routing for strong-consistency reads.

• Primary zone-based routing for strong consistency reads: In this mode, the primary zone is configured by using an ODP parameter. ODP routes a strong-consistency read statement for which routing calculation cannot be performed to an OBServer node in the primary zone. For more information, see Primary zone-based routing for strong-consistency reads.

• Strategy-based routing: ODP routes statements based on rules of the configured routing strategy. For more information, see Strategy-based routing.

• Distributed transaction routing: After distributed transaction routing is enabled by using the ODP parameter enable_transaction_internal_routing, statements in a transaction do not need to be force routed to the OBServer node that starts the transaction. For more information, see Distributed transaction routing.

• Rerouting: Rerouting is enabled by using an ODP parameter. After a statement is routed to an OBServer node, if no partition is hit or the distributed transaction cannot be executed on this OBServer node, ODP can accurately reroute the statement. For more information, see Rerouting.

• Forcible routing: ODP decides whether to perform forcible routing. Forcible routing is performed in the following cases. For more information, see Forcible routing.

  • For non-distributed transaction routing, statements in a transaction are force routed to the OBServer node that starts the transaction.

  • For session-level temporary table-based routing, a query is force routed to the OBServer node where the temporary table is queried for the first time.

  • Session reuse-based routing: If routing calculation fails and the enable_cached_server parameter is set to True, ODP force routes a query to the OBServer node where the session resides the last time.

  • Cursor/Piece-based routing: When the client uses cursors/pieces to obtain/upload data, all requests are force routed to the same OBServer node.

This chapter provides examples to describe how to use different routing modes.