On 08/04/2025 00:27, Tim N wrote:
Thanks for clarifying that. Does BackupManager support auto-scaling
Yes, if you use a cluster membership mechanism that allows that.
and
cycled restarts of all nodes (for web-app upgrades) without losing the
user's session?
Yes, but you need to trigger the restarts manually. There is no
mechanism to automate that.
If the backup node is restarted...the backup is lost isn't
it?
That isn't how the backup manager works. There isn't a single backup
node. TL;DR backups for one node are distributed around the cluster.
There are several presentations by me on the Tomcat website that discuss
this. Maybe start with this one from slide 12.
Slides:
https://tomcat.apache.org/presentations/2013-02-acna-Apache-Tomcat-Clustering.pdf
Video:
https://www.youtube.com/watch?v=rX1zm11AXcA
HTH,
Mark
On Fri, Apr 4, 2025 at 8:23 PM Mark Thomas <ma...@apache.org> wrote:
On 04/04/2025 02:42, Chuck Caldarale wrote:
On 2025 Apr 3, at 19:57, Tim N <tnti...@gmail.com> wrote:
For a long time up to the latest version 11 documentation, there has
been a
recommended maximum limit of 4 nodes per cluster.
https://tomcat.apache.org/tomcat-11.0-doc/cluster-howto.html
"This works great for smaller clusters, but we don't recommend it for
larger clusters — more than 4 nodes or so."
Are there any plans to improve this?
It's a pity to have to change the architecture when going from, say, 3
notes to 8 by introducing farms. What is the next simplest free cluster
to
move to? Redis? Any idea how cluster farming compares with redis?
What other options are there?
I may be misreading the documentation, but I think the 4-node
restriction applies to the DeltaManager, and using the BackupManager
removes the limitation.
Chuck is correct. The issue with the DeltaManager is that the cluster
traffic scales with the square of the number of nodes. For the
BackupManager traffic scales linearly with the number of nodes.
The limit of 4 is one of those values that should work with most
applications. Depending on your application, the actual limit may be
higher.
Mark
- Chuck
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
