You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/interfaces/ClusterOptions.md
+3-3Lines changed: 3 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -29,6 +29,6 @@ Options for Cluster constructor.
29
29
| <aid="shardnamer"></a> `shardNamer?`|`null`\|[`ShardNamer`](../classes/ShardNamer.md)| Info on how to build/parse Shard names. |
30
30
| <aid="shardsdiscoverintervalms"></a> `shardsDiscoverIntervalMs?`|`MaybeCallable`\<`number`\>| How often to run Shards rediscovery in normal circumstances. |
31
31
| <aid="shardsdiscoverintervaljitter"></a> `shardsDiscoverIntervalJitter?`|`MaybeCallable`\<`number`\>| Jitter for shardsDiscoverIntervalMs and reloadIslandsIntervalMs. |
32
-
| <aid="locateislanderrorretrycount"></a> `locateIslandErrorRetryCount?`|`MaybeCallable`\<`number`\>| Used in the following situations: 1. If we think that we know Island of a particular Shard, but an attempt to access it fails, this means that maybe the Shard is migrating to another Island. In this case, we wait a bit and retry that many times. We should not do it too many times though, because all DB requests will be blocked waiting for the resolution. 2. If we sent a write request to a Client, but it appeared that this Client is a replica, and the master moved to some other Client. In this case, we wait a bit and ping all Clients of the Island to refresh, who is master and who is replica. |
33
-
| <aid="locateislanderrorrediscoverclusterdelayms"></a> `locateIslandErrorRediscoverClusterDelayMs?`|`MaybeCallable`\<`number`\>| How much time to wait before we retry rediscovering the entire Cluster. The time here should be just enough to wait for switching the Shard from one Island to another (typically quick). |
34
-
| <aid="locateislanderrorrediscoverislanddelayms"></a> `locateIslandErrorRediscoverIslandDelayMs?`|`MaybeCallable`\<`number`\>| How much time to wait before sending discover requests to all Clients of the Island trying to find the new master. The time here may reach several seconds, since some DBs shut down the old master and promote some replica to it not simultaneously. |
32
+
| <aid="runonsharderrorretrycount"></a> `runOnShardErrorRetryCount?`|`MaybeCallable`\<`number`\>| Used in the following situations: 1. If we think that we know the Island of a particular Shard, but an attempt to access it fails. This means that maybe the Shard is migrating to another Island. So, we wait a bit and retry that many times. We should not do it too many times though, because all DB requests will be blocked waiting for the resolution. 2. If we sent a WRITE request to a Client, but it appeared that this Client is a replica, and the master moved to some other Client. In this case, we wait a bit and ping all Clients of the Island to refresh, who is master and who is replica. |
33
+
| <aid="runonsharderrorrediscoverclusterdelayms"></a> `runOnShardErrorRediscoverClusterDelayMs?`|`MaybeCallable`\<`number`\>| How much time to wait before we retry rediscovering the entire Cluster after a Shard-to-Island resolution error. The time here should be just enough to wait for switching the Shard from one Island to another (typically quick). |
34
+
| <aid="runonsharderrorrediscoverislanddelayms"></a> `runOnShardErrorRediscoverIslandDelayMs?`|`MaybeCallable`\<`number`\>| How much time to wait before sending discover requests to all Clients of the Island trying to find the new master (or to reconnect). The time here may reach several seconds, since some DBs shut down the old master and promote some replica to it not simultaneously. |
0 commit comments