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

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

Figure 1: Syntax:

1  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 2: 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 3: 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 4: 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 5: 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))