onstat -g shard command: Print information about the shard definition

Use the onstat -g shard command to display information about the sharding definition.


Syntax:

>>-onstat-- -g--shard------------------------------------------><

Output description

The output of the onstat -g shard command shows the following information without field labels.

Sharding definition name: The name of the sharding definition.
Database name: The name of the database that contains the table or collection that is distributed across multiple shards.
Table owner name: The owner of the table or collection that is distributed across multiple shards.
Table name: The name of the table or collection that is distributed across multiple shards.
Shard key: The shard key that is used for distributing rows or documents. Value can be a table column, document field, or an expression.
Sharding strategy: The method for determining which database server a new row or document is applied on. Values can be HASH (hash algorithm), CONSISTENT HASH (consistent hash algorithm), or EXPRESSION (expression).
Sharding type: Specifies source-server action after a row or document is replicated to a target server. Values can be DELETE, KEEP, or INFORMATIONAL.
Shard optimization: Specifies if queries can skip shard servers that do not contain relevant data. Values can be ENABLED or NOT ENABLED.
Version column: Specifies the column or key that is used when Enterprise Replication attempts to verify that a source row or document was not updated. The value is a column or document field.
Sharding rule: The rule for replicating data to a specific database server.

Example: Output for a sharding definition that uses consistent hash-based sharding

For this example, you have a sharding definition that was created by the following command:

cdr define shardCollection collection_1 database_1:john.customers_1
   --type=delete --key=b --strategy=chash --partitions=3 --versionCol=column_3
   g_shard_server_1
   g_shard_server_2
   g_shard_server_3

The following example shows output when the onstat -g shard command is run on g_shard_server_1, g_shard_server_2, or g_shard_server_3.

Figure 1. onstat -g shard command output for a sharding definition that uses a consistent hash algorithm to distribute data across multiple shard servers.

collection_1 database_1:john.customers_1 key:b CONSISTENT HASH:DELETE SHARD OPTIMIZATION:NOT ENABLED
Matching for delete:column_3
   g_shard_server_1 (65542) (mod(abs(ifx_checksum(b::LVARCHAR, 0)), 10000) between 4019 and 5469)
                             or (mod(abs(ifx_checksum(b::LVARCHAR, 0)), 10000) between 5719 and 6123)  
                             or (mod(abs(ifx_checksum(b::LVARCHAR, 0)), 10000) between 2113 and 2652) 
   g_shard_server_2 (65543) (mod(abs(ifx_checksum(b::LVARCHAR, 0)), 10000) between 6124 and 7415)
                             or (mod(abs(ifx_checksum(b::LVARCHAR, 0)), 10000) between 5470 and 5718)
                             or (mod(abs(ifx_checksum(b::LVARCHAR, 0)), 10000) between 7416 and 7873) 
   g_shard_server_3 (65544) (mod(abs(ifx_checksum(b::LVARCHAR, 0)), 10000) between 2653 and 3950)
                             or mod(abs(ifx_checksum(b::LVARCHAR, 0)), 10000) >= 7874
                             or mod(abs(ifx_checksum(b::LVARCHAR, 0)), 10000) < 2113
                             or (mod(abs(ifx_checksum(b::LVARCHAR, 0)), 10000) between 3951 and 4018)

Each shard server has three hashing partitions.

Example: Output for a sharding definition that uses hash-based sharding

For this example, you have a sharding definition that was created by the following command:

cdr define shardCollection collection_1 database_1:josh.customers_1
   --type=delete --key=column_2 --strategy=hash --versionCol=column_3
   g_shard_server_A
   g_shard_server_B
   g_shard_server_C
   g_shard_server_D

The following example shows output when the onstat -g shard command is run on g_shard_server_A, g_shard_server_B, g_shard_server_C, or g_shard_server_D.

Figure 2. onstat -g shard command output for a sharding definition that uses a hash algorithm to distribute data across multiple shard servers.

collection_1 database_1:josh.customers_1 key:column_2 HASH:DELETE SHARD OPTIMIZATION:ENABLED
Matching for delete:column_3
g_shard_server_A (65545) mod(ifx_checksum(column_2::LVARCHAR, 0), 4) = 0
g_shard_server_B (65546) mod(ifx_checksum(column_2::LVARCHAR, 0), 4) in (1, -1)
g_shard_server_C (65547) mod(ifx_checksum(column_2::LVARCHAR, 0), 4) in (2, -2)
g_shard_server_D (65548) mod(ifx_checksum(column_2::LVARCHAR, 0), 4) in (3, -3)

Example: Output for a sharding definition that uses expression-based sharding

For this example, you have a sharding definition that was created by the following command:

cdr define shardCollection collection_2 database_2:john.customers_2
   --type=keep --key=state --strategy=expression --versionCol=version_column
   g_shard_server_F "IN ('AL','MS','GA')"
   g_shard_server_G "IN ('TX','OK','NM')"
   g_shard_server_H "IN ('NY','NJ')"
   g_shard_server_I REMAINDER

The following example shows output when the onstat -g shard command is run on g_shard_server_F, g_shard_server_G, g_shard_server_H, or g_shard_server_I.

Figure 3. onstat -g shard command output for a sharding definition that uses an expression to distribute data across multiple database servers.

collection_2 database_2:john.customers_2 key:state EXPRESSION:KEEP SHARD OPTIMIZATION:ENABLED
Matching for delete:version_column
g_shard_server_F (65564) state IN ('AL','MS','GA')
g_shard_server_G (65565) state IN ('TX','OK','NM')
g_shard_server_H (65566) state IN ('NY','NJ')
g_shard_server_I (65567) not ((state IN ('AL','MS','GA')) or (state IN('TX','OK','NM'))
or (state IN ('NY','NJ')))

Example: Output for a sharding definition that uses a BSON shard key and expression-based sharding

For this example, you have a sharding definition that was created by the following command:

cdr define shardCollection collection_3 database_3:susan.customers_3
   -t delete -k bson_value_lvarchar(data,'age') -s expression -v version
   g_shard_server_J "BETWEEN 0 and 20"
   g_shard_server_K "BETWEEN 21 and 62"
   g_shard_server_L "BETWEEN 63 and 100"
   g_shard_server_M  REMAINDER

The following example shows output when the onstat -g shard command is run on shard_server_J, shard_server_K, shard_server_L, or shard_server_M.

Figure 4. onstat -g shard command output for a sharding definition that uses a BSON shard key and an expression to distribute data across multiple database servers.

collection_3 database_3:susan.customers_3 key:bson_value_lvarchar(data,'age')
EXPRESSION:DELETE SHARD OPTIMIZATION:ENABLED
Matching for delete:version
g_shard_server_J (65568) bson_value_lvarchar(data,'age') BETWEEN 0 and 20"
g_shard_server_K (65569) bson_value_lvarchar(data,'age') BETWEEN 21 and 62"
g_shard_server_L (65570) bson_value_lvarchar(data,'age')BETWEEN 63 and 100"
g_shard_server_M (65571) not((bson_value_lvarchar(data,'age') BETWEEN 0 and 20)
or (bson_value_lvarchar(data,'age') BETWEEN 21 and 62) or (bson_value_lvarchar
(data,'age') BETWEEN 63 and 100))