009d23df45
When using Galera, the wsrep_sync_wait option [1] can change the behavior of a variety of Galera DQL/DML statements such that a particular operation will pause until outstanding write-sets are fully persisted to the local node. The setting supersedes the previous boolean parameter wsrep_causal_reads which only affected SELECT, with an updated approach that allows for fine-grained control of so-called "causality checks" on individual statement types. The legacy-compatible setting of '1' indicates that READ/SELECT/BEGIN operations should proceed only after any pending writesets are fully available. The use case for this setting is for an application that is running operations on multiple Galera nodes simultaenously. An application that commits data on one node, and then immediately uses a different connection (on a potentially different node) to SELECT that data, may fail to see those changes if "causality checks" for SELECT are not enabled. While a COMMIT operation in Galera will block locally until all other nodes approve of the writeset, the operation does not block for the subsequent period of time when other nodes are actually persisting that writeset. Setting up "causal reads" in this case indicates that a SELECT operation will wait until any writesets in progress are available, thus maintaining serialization between the COMMIT and subsequent SELECT. As the name implies, wsrep_sync_wait adds...waiting! to the operation, and thus directly impacts performance by adding latency to SELECT operations or to the operations that have been selected for causality checks, to the degree that concurrent writesets are expected to be present. Since it's not expected that most if any Openstack applications actually need this setting in order to be effective with Galera multi-master operation, and as the setting is available within client session scope and also impacts performance, making it available on a per-application basis means that specific applications which may see issues under load can choose to enable this setting, much in the way any other "transaction isolation" settings might be made, without having to add a cluster-wide performance penalty by setting it at the Galera server level. [1] https://mariadb.com/docs/ent/ref/mdb/system-variables/wsrep_sync_wait/ Change-Id: Iee7afcac8ba952a2d67a9ad9dd0e4eae3f42518e
87 lines
2.5 KiB
INI
87 lines
2.5 KiB
INI
[tox]
|
|
minversion = 3.18.0
|
|
envlist = py3,pep8
|
|
ignore_basepython_conflict = true
|
|
|
|
[testenv]
|
|
basepython = python3
|
|
allowlist_externals =
|
|
env
|
|
passenv =
|
|
OS_TEST_DBAPI_ADMIN_CONNECTION
|
|
setenv =
|
|
OS_STDOUT_CAPTURE=true
|
|
OS_STDERR_CAPTURE=true
|
|
BASECOMMAND=stestr run
|
|
{postgresql,all}: PIFPAF_POSTGRESQL=pifpaf -g OS_TEST_DBAPI_ADMIN_CONNECTION run postgresql --
|
|
{mysql,all}: PIFPAF_MYSQL=pifpaf -g OS_TEST_DBAPI_ADMIN_CONNECTION run mysql --
|
|
{mysql,postgresql,all}: BASECOMMAND={toxinidir}/tools/run-pifpaf-tests.sh
|
|
# TODO(stephenfin): Remove once we bump our upper-constraint to SQLAlchemy 2.0
|
|
SQLALCHEMY_WARN_20=1
|
|
deps =
|
|
-c{env:TOX_CONSTRAINTS_FILE:https://releases.openstack.org/constraints/upper/master}
|
|
-r{toxinidir}/test-requirements.txt
|
|
-r{toxinidir}/requirements.txt
|
|
commands =
|
|
{env:PIFPAF_MYSQL:} {env:PIFPAF_POSTGRESQL:} {env:BASECOMMAND:} {posargs}
|
|
|
|
[testenv:pep8]
|
|
commands =
|
|
pre-commit run -a
|
|
# Run security linter
|
|
bandit -r oslo_db -x tests -x oslo_db/tests -n5 --skip B105,B311
|
|
|
|
[testenv:venv]
|
|
commands = {posargs}
|
|
|
|
[testenv:cover]
|
|
setenv =
|
|
PYTHON=coverage run --source oslo_db --parallel-mode
|
|
commands =
|
|
stestr run {posargs}
|
|
coverage combine
|
|
coverage html -d cover
|
|
coverage xml -o cover/coverage.xml
|
|
|
|
[testenv:docs]
|
|
allowlist_externals =
|
|
rm
|
|
deps =
|
|
{[testenv]deps}
|
|
-r{toxinidir}/doc/requirements.txt
|
|
commands =
|
|
rm -rf doc/build doc/source/reference/api
|
|
doc8 -e .rst CONTRIBUTING.rst HACKING.rst README.rst doc/source
|
|
sphinx-build -W --keep-going -b html doc/source doc/build/html
|
|
|
|
[testenv:releasenotes]
|
|
allowlist_externals =
|
|
rm
|
|
deps =
|
|
-c{env:TOX_CONSTRAINTS_FILE:https://releases.openstack.org/constraints/upper/master}
|
|
-r{toxinidir}/doc/requirements.txt
|
|
commands =
|
|
rm -rf releasenotes/build
|
|
sphinx-build -a -E -W -d releasenotes/build/doctrees --keep-going -b html releasenotes/source releasenotes/build/html
|
|
|
|
[flake8]
|
|
# E123, E125 skipped as they are invalid PEP-8.
|
|
ignore = E123,E125,W504
|
|
show-source = True
|
|
exclude=.venv,.git,.tox,dist,doc,*lib/python*,*egg,build
|
|
|
|
[hacking]
|
|
import_exceptions =
|
|
oslo_db._i18n
|
|
|
|
[testenv:bindep]
|
|
# Do not install any requirements. We want this to be fast and work even if
|
|
# system dependencies are missing, since it's used to tell you what system
|
|
# dependencies are missing! This also means that bindep must be installed
|
|
# separately, outside of the requirements files, and develop mode disabled
|
|
# explicitly to avoid unnecessarily installing the checked-out repo too (this
|
|
# further relies on "tox.skipsdist = True" above).
|
|
deps = bindep
|
|
commands = bindep test
|
|
usedevelop = False
|