Skip to content

Commit 5383320

Browse files
committed
Amend text after tech feedback
1 parent 20a0638 commit 5383320

File tree

1 file changed

+22
-27
lines changed

1 file changed

+22
-27
lines changed

doc/release/3.4.0.rst

Lines changed: 22 additions & 27 deletions
Original file line numberDiff line numberDiff line change
@@ -123,16 +123,20 @@ for example:
123123
Now supervised failover coordinator supports three bootstrap strategies:
124124
native, supervised, auto.
125125

126-
The new ``native `` strategy acts more or less similar to the ``auto`` strategy,
127-
but relaxes its limitations. It is based on the supervised strategy and basically
128-
performs two things:
129-
* issues ``box.ctl.make_bootstrap_leader({graceful = true})`` to bootstrap
130-
a replicaset;
131-
* issues ``box.ctl.make_bootstrap_leader()`` to keep the bootstrap leader
132-
record pointing to the instance that is currently in the RW mode (to register
133-
new replicas).
134-
135-
To enable the ``native `` bootstrap strategy, set it in the ``replication`` section
126+
The new ``native`` strategy relaxes the limitations of the ``auto`` strategy,
127+
but has different under-the-hood implementation (based on the ``supervised`` strategy).
128+
Otherwise, it acts similar to the ``auto`` strategy.
129+
130+
In effect, it helps resolve these two problems:
131+
* Avoid the error ``Some replica set members were not specified in box.cfg.replication``
132+
in the following cases:
133+
* several replicas join at the same time,
134+
* the replica set includes non-anonymous CDC instances,
135+
* ``_cluster`` contains expelled replicas.
136+
* Make the database get bootstrapped upon the coordinator's command rather than
137+
let the instances boostrap it on their own.
138+
139+
To enable the ``native`` bootstrap strategy, set it in the ``replication`` section
136140
of the cluster's configuration, together with a proper failover strategy
137141
(for ``native``, you can choose any failover strategy you like, for example ``supervised``):
138142

@@ -177,23 +181,14 @@ maintain compatibility and consistency with other privilege types.
177181

178182
Three new methods are now available in the ``config`` module:
179183

180-
* ``has_role(<role_name>, {instance = <instance_name})`` returns ``true`` if
181-
the instance with the name ``<instance_name>`` has the role ``<role_name>``
182-
enabled in the current configuration, or ``false`` if not.
183-
The second argument is optional: if not provided, the check is performed
184-
for the instance the method is called on.
185-
186-
* ``is_router({instance = <instance_name})`` returns ``true`` if the instance
187-
with the name ``<instance_name>`` is a vshard router, according to the current
188-
configuration, or ``false`` if not.
189-
The argument is optional: if not provided, the check is performed for
190-
the instance the method is called on.
191-
192-
* ``is_storage({instance = <instance_name})`` returns ``true`` if the instance
193-
with the name ``<instance_name>`` is a vshard storage, according to the current
194-
configuration, or ``false`` if not.
195-
The argument is optional: if not provided, the check is performed for
196-
the instance the method is called on.
184+
* ``config:has_role('myrole')`` tells whether the current instance has the role ``myrole``, and
185+
``config:has_role('myrole', {instance = 'i-001'})`` does the same for the specified instance (``i-001``).
186+
187+
* ``config:is_router()`` tells whether the current instance is a vshard router, and
188+
``config:is_router({instance = 'i-002'})`` does the same for the specified instance (``i-002``).
189+
190+
* ``config:is_storage()`` tells whether the current instance is a vshard storage, and
191+
``config:is_storage({instance = 'i-003'})`` does the same for the specified instance (``i-003``).
197192

198193
.. _3-4-storage-client-api:
199194

0 commit comments

Comments
 (0)