Hello Justin! VHA is a commercial product, so we should probably keep it short of private as this is an open-source mailing-list.
However, since I'm sure the answer will be useful for other people, let's answer publicly :-) VHA is a fire-and-forget tool, outside of the critical path so that replication requests failing (or being rate-limited) don't cause harm. Purging, on the other hand, needs to be very vocal about failed purge requests failing as your cache consistency is at stake, so while VHA can do it, it's a bad idea. However, VHA uses a tool named broadcaster which can be used on its own to do exactly what you need: replicate a single request for the CMS backend to the whole cluster, and report back so you can act on failures. Cheer, -- Guillaume Quintard On Mon, Jun 14, 2021 at 7:39 AM Justin Lloyd <[email protected]> wrote: > Hi all, > > > > I just saw the new Varnish HA video > <https://www.youtube.com/watch?v=KhqVdKe2RAU> and was wondering if VHA’s > node synchronization would obviate the need for all of the Varnish nodes to > be listed in the MediaWiki Varnish caching configuration > <https://www.mediawiki.org/wiki/Manual:Varnish_caching>. MediaWiki uses > the list of cache nodes to send HTTP PURGE requests to invalidate cached > pages when they are updated. So with VHA, could MediaWiki just be > configured with a single hostname or floating IP address (e.g. keepalived) > that points to the Varnish cluster so that the cluster could handle > replicating the PURGE requests? > > > > Thanks, > > Justin > > > _______________________________________________ > varnish-misc mailing list > [email protected] > https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc >
_______________________________________________ varnish-misc mailing list [email protected] https://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
