diff --git a/doc/reference/configuration/cfg_replication.rst b/doc/reference/configuration/cfg_replication.rst index e785ea281b..7990cc1e53 100644 --- a/doc/reference/configuration/cfg_replication.rst +++ b/doc/reference/configuration/cfg_replication.rst @@ -346,6 +346,11 @@ | Environment variable: TT_REPLICATION_SYNC_TIMEOUT | Dynamic: **yes** + .. NOTE:: + + The default ``replication_sync_timeout`` value is going to be changed in future versions from ``300`` to ``0``. + You can learn the reasoning behind this decision from the :ref:`Default value for replication_sync_timeout ` topic, which also describes how to try the new behavior in the current version. + .. _cfg_replication-replication_timeout: .. confval:: replication_timeout diff --git a/doc/reference/reference_lua/compat/box_cfg_replication_sync_timeout.rst b/doc/reference/reference_lua/compat/box_cfg_replication_sync_timeout.rst index 348fc5beed..68ce977f40 100644 --- a/doc/reference/reference_lua/compat/box_cfg_replication_sync_timeout.rst +++ b/doc/reference/reference_lua/compat/box_cfg_replication_sync_timeout.rst @@ -3,7 +3,7 @@ Default value for replication_sync_timeout ========================================== -Having a non-zero ``replication_sync_timeout`` gives a user the false assumption that the ``box.cfg{replication = ...}`` call returns only when the configured node is synced with all the other nodes. +Having a non-zero :ref:`replication_sync_timeout ` gives a user the false assumption that the ``box.cfg{replication = ...}`` call returns only when the configured node is synced with all the other nodes. This is mostly true for the big ``replication_sync_timeout`` values, but it is not 100% guaranteed. In other words, a user still has to check if the node is synced, or the sync just timed out. Besides, while ``replication_sync_timeout`` is ticking, you cannot reconfigure ``box`` with another ``box.cfg`` call, which hardens reconfiguration. @@ -13,7 +13,7 @@ It is decided to set the ``replication_sync_timeout`` to zero by default. Old and new behavior -------------------- -The ``compat`` module allows you chose between +The ``compat`` module allows you to choose between * the old behavior: ``box.cfg.replication_sync_timeout`` is 300 seconds by default @@ -59,8 +59,8 @@ Known compatibility issues At this point, no incompatible modules are known. -Detecting issues in you codebase --------------------------------- +Detecting issues in your codebase +--------------------------------- We expect issues with a user assuming that the node is not in the orphan state (``box.info.status ~= "orphan"``) after the ``box.cfg{replication=...}`` call returns. This is not true with the new behaviour. To simulate the old behavior, one may add a ``box.ctl.wait_rw()`` call after the ``box.cfg{}`` call. diff --git a/doc/reference/reference_lua/compat/fiber_channel_close_mode.rst b/doc/reference/reference_lua/compat/fiber_channel_close_mode.rst index 5be0b21d0a..756e418307 100644 --- a/doc/reference/reference_lua/compat/fiber_channel_close_mode.rst +++ b/doc/reference/reference_lua/compat/fiber_channel_close_mode.rst @@ -99,8 +99,8 @@ Known compatibility issues At this point, no incompatible modules are known. -Detecting issues in you codebase --------------------------------- +Detecting issues in your codebase +--------------------------------- The new behavior is mostly backward compatible. The only known problem that can appear is when the code relies on channel being entirely closed after ``ch:close()`` and ``ch:get()`` returning ``nil``. diff --git a/doc/reference/reference_lua/compat/fiber_slice_default.rst b/doc/reference/reference_lua/compat/fiber_slice_default.rst index a24c06376c..4defe47825 100644 --- a/doc/reference/reference_lua/compat/fiber_slice_default.rst +++ b/doc/reference/reference_lua/compat/fiber_slice_default.rst @@ -23,8 +23,8 @@ Known compatibility issues At this point, no incompatible modules are known. -Detecting issues in you codebase --------------------------------- +Detecting issues in your codebase +--------------------------------- If you see a warning like this in the log: diff --git a/doc/reference/reference_lua/compat/json_escape_forward_slash.rst b/doc/reference/reference_lua/compat/json_escape_forward_slash.rst index 29eb945524..43de9ae7f9 100644 --- a/doc/reference/reference_lua/compat/json_escape_forward_slash.rst +++ b/doc/reference/reference_lua/compat/json_escape_forward_slash.rst @@ -39,8 +39,8 @@ Known compatibility issues At this point, no incompatible modules are known. -Detecting issues in you codebase --------------------------------- +Detecting issues in your codebase +--------------------------------- Both encoding styles are correct from the JSON standard standpoint, but if your module relies on encodings results bytewise, it may break with this change. Be cautious if you do the following: diff --git a/doc/reference/reference_lua/compat/sql_seq_scan_default.rst b/doc/reference/reference_lua/compat/sql_seq_scan_default.rst index f5fe564ee5..2a6aee0a75 100644 --- a/doc/reference/reference_lua/compat/sql_seq_scan_default.rst +++ b/doc/reference/reference_lua/compat/sql_seq_scan_default.rst @@ -88,8 +88,8 @@ Known compatibility issues At this point, no incompatible modules are known. -Detecting issues in you codebase --------------------------------- +Detecting issues in your codebase +--------------------------------- We expect most SELECTs that do not use indexes to fail after the ``sql_seq_scan`` session setting is set to false. The best way to avoid this is to refactor the query to use indexes. diff --git a/doc/reference/reference_lua/compat/yaml_pretty_multiline.rst b/doc/reference/reference_lua/compat/yaml_pretty_multiline.rst index 239b3ea523..d9745b1724 100644 --- a/doc/reference/reference_lua/compat/yaml_pretty_multiline.rst +++ b/doc/reference/reference_lua/compat/yaml_pretty_multiline.rst @@ -47,8 +47,8 @@ Known compatibility issues At this point, no incompatible modules are known. -Detecting issues in you codebase --------------------------------- +Detecting issues in your codebase +--------------------------------- Both encoding styles are correct from the YAML standard standpoint, but if your module relies on encodings results bytewise, it may break with this change. Be cautious if you do the following: