Filtered Forwarding Replica Reseed ("ffr_reseed")

Welcome

This is the home of the Filtered Forwarding Replica Reseed project.

Overview

Filtered forwarding replicas are wicked awesome for certain use cases.

When you have a massive mondo "one source of truth" data set, but you only need a slice of it available at a particular geographic location, then a filtered forwarding replica is worthy of consideration as s topology option at your site.

The filtering here is achieved as by setting the 'RevisionDataFilter:' field of using a server spec. It defines the scope of what you want filtered in or out of a given replica.

But there's a catch. A filtered forwarding replica's scope is not dynamic. Any change to the replication scope, either expanding or contracting the scope of the RevisionDataFilter, requires reseeding the replica. To reseed a filtered forwarding replica, a filtered checkpoint must first be created. The scripts included here provide sample automation to create a filtered checkpoint and reseed a replica from the filtered checkpoint.

Reseeding is necessary when the filter changes because Bad Things can happen if you try to change the filter scope dynamically. If you expand the scope, you'll be receiving new joural records for which there is no baseline data (since you started with a filtered checkpoint). If you shrink the scope, then you'll have stale baseline data which can't receive updates. These are things you just don't want happening.

The sample scripts assume the Consulting Server Deployment Package (SDP) is in use. This process takes advantage of the SDP's offline checkpont strategy to achieve the reseed operation with no downtime for the master server. Downtime is required at the replica site to reseed the local databases.

This pair of scripts provide a sample automation to reseed a filtered forwarding replica of a master Perforce server. It need not be run routinely. Instead it can be run on occasion as needed to reseed the filtered forwarding replica. This is needed whenever the scope of the filter for the forwarding replica changes.

The reseed process is initiated by a human on the master Perforce server. It relies on SSH keys to get from the master server to the replica (one-way only). The filtered checkpoint is created from offline databases on the master server, and shipped to the replica site. The script called by a human on the master server then calls its counterpart on the replica server, and initiates the blasting and recreation of the replica at that site, using the filtered checkpoint.

Feedback is appreciated!

Contact us at Consulting@Perforce.com for more informatin.

Project Status

Sample bash shell scripts with internal comments are provided here. No active development is planned.