We would like to use REPLICATE DATABASE / STOP REPLICATION to refresh our qa and staging database from our production database. Couple of question in relation to that:
On our QA/STAGING cluster, we have default_partitions_per_leaf=4 but PROD has default_partitions_per_leaf=16. What impact if any will that have on the replication?
Is there another recommended method to do this type of activity?
This will not have an impact on replication - that default value is used to automatically calculate how many partitions a database has if left unspecified, based on the number of leaves in the cluster. After creating a database, the number of partitions is fixed, even if you add more leaves. Replicas always have the same number of partitions as the source database, regardless of that setting.
It depends on what you’re trying to do exactly - replication is appropriate if you want it to be continuously refreshed, but there’s the current disadvantage that you lose some transactional consistency on the replica clusters (each partition replicates independently); if that’s important for you, and you don’t care about keeping them continuously refreshed, you could use restore backups of the production cluster onto QA/STAGING. Further, it can also introduce overhead that can affect the workload, although that’s highly dependent on where your bottlenecks are - the overhead will be mainly in the network, so if you have enough bandwidth available, you shouldn’t notice it.