wal_queue_max_size is set too late on initial box.cfg
#10013
Assignees
Labels
Comments
sergepetrenko
added
bug
sergepetrenko
added a commit
to sergepetrenko/tarantool
that referenced
this issue
May 16, 2024
wal_queue_max_size took effect only after the initial box.cfg call, meaning that users with non-zero `replication_sync_timeout` still synced using the default 16 Mb queue size. In some cases the default was too big and the same issues described in tarantool#5536 arised. Fix this. Closes tarantool#10013 NO_DOC=bugfix
sergepetrenko
added a commit
to sergepetrenko/tarantool
that referenced
this issue
May 16, 2024
wal_queue_max_size took effect only after the initial box.cfg call, meaning that users with non-zero `replication_sync_timeout` still synced using the default 16 Mb queue size. In some cases the default was too big and the same issues described in tarantool#5536 arose. Fix this. Closes tarantool#10013 NO_DOC=bugfix
sergepetrenko
added a commit
to sergepetrenko/tarantool
that referenced
this issue
May 20, 2024
wal_queue_max_size took effect only after the initial box.cfg call, meaning that users with non-zero `replication_sync_timeout` still synced using the default 16 Mb queue size. In some cases the default was too big and the same issues described in tarantool#5536 arose. Fix this. Closes tarantool#10013 NO_DOC=bugfix
sergepetrenko
added a commit
to sergepetrenko/tarantool
that referenced
this issue
May 21, 2024
wal_queue_max_size took effect only after the initial box.cfg call, meaning that users with non-zero `replication_sync_timeout` still synced using the default 16 Mb queue size. In some cases the default was too big and the same issues described in tarantool#5536 arose. Fix this. Closes tarantool#10013 NO_DOC=bugfix (cherry picked from commit ab0f791)
sergepetrenko
added a commit
to sergepetrenko/tarantool
that referenced
this issue
May 21, 2024
wal_queue_max_size took effect only after the initial box.cfg call, meaning that users with non-zero `replication_sync_timeout` still synced using the default 16 Mb queue size. In some cases the default was too big and the same issues described in tarantool#5536 arose. Fix this. Closes tarantool#10013 NO_DOC=bugfix (cherry picked from commit ab0f791)
This was referenced May 21, 2024
sergepetrenko
added a commit
that referenced
this issue
May 21, 2024
wal_queue_max_size took effect only after the initial box.cfg call, meaning that users with non-zero `replication_sync_timeout` still synced using the default 16 Mb queue size. In some cases the default was too big and the same issues described in #5536 arose. Fix this. Closes #10013 NO_DOC=bugfix (cherry picked from commit ab0f791)
sergepetrenko
added a commit
that referenced
this issue
May 21, 2024
wal_queue_max_size took effect only after the initial box.cfg call, meaning that users with non-zero `replication_sync_timeout` still synced using the default 16 Mb queue size. In some cases the default was too big and the same issues described in #5536 arose. Fix this. Closes #10013 NO_DOC=bugfix (cherry picked from commit ab0f791)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bug description
wal_queue_max_sizeis a dynamic cfg parameter, and it's applied byload_cfgonly afterbox_cfg_xc()finishes.In case
box_cfg_xcincludes syncing with a remote master, all the syncing wil happen with defaultwal_queue_max_sizesetting, 16 megabytes. Turns out, the default is too big for some applications when rows are tiny and wal_queue allows hundreds of thousands of rows to enter the queue in one event loop cycle. If this is the case, the same symptoms already discussed in #5536 appear, and the node is never in time to sync with the master.Reproduced on Tarantool 2.8.4.
A workaround for Tarantool 2.8.4 is to start with
box.cfg{replication_sync_timeout=0.01}. Then "sync" stage ends almost immediately and the desiredwal_queue_max_sizewill be applied as soon as possible.The text was updated successfully, but these errors were encountered: