Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Store event counters and client application timestamps per node to improve performance of replication #1819
In replicated setups like Galera, we sometimes have problems with multiple nodes trying to write to the same database row at the same time. This happens especially in case of the
We could try to mitigate the issue by having each privacyIDEA node only write counters to its own private table row. As an example, with
Then, A updates an event counter like this:
And B updates an event counter like this:
C updates an event counter like this:
Then, when retrieving the event counter value with a given name, we would need to sum up all rows of all nodes:
This way, each Galera node would only try to write to its own private row of
However, this would only work if each privacyIDEA node has its own Galera node. It wouldn't work, for example, if the privacyIDEA nodes connect to a load balancer that selects the Galera node to use.
I think it would even work, if there are several privacyIDEA Applications servers all writing to the same database, since each application server has it's own node-specifer:
nodeA, nodeB, nodeC writing to one database would result in each node updating it's own row.
I like this idea a lot and I think we should address this in version 3.2.
Do you mean the scenario that we have no database-level replication in place, but three privacyIDEA servers
I performed some tests of the code #1833, which implements private rows for event counters.
Results on current master
In total, we have 56 failed requests due to deadlocks (but some of them due to a deadlock in the
Results with #1833
In total, we have 11 deadlocks, probably due to the
With #1833, we have a lot less deadlocks (only 11 vs 56), but request handling seems to be slightly slower. :)
So it's questionable whether we should merge this.