Hi,

Generally, I like the DDL approach more than using the configuration file. Additional benefit to ones listed is possibility to create various front-ends for replication configuration / integration of such functionality into existing Firebird management tools.

Comments to specific question inline...

Dne 21. 02. 19 v 9:14 Dmitry Yemanov napsal(a):

One thing I'm worried about is whether it's enough to have a single global replication set or maybe it's useful to have many independent replication sets. How they can be used, for example:

It would be nice to has such feature in future.

1) Two slightly different global replications sets are defined, only one of them is active at a time, but we can switch between them (e.g. via enable/disable commands)

Hmm, can see an use case for it that would solve some problem and not cause trouble at the same time. I sense a great potential for users to shoot themselves to foot.

2) Different tables (separated by some rule) are included into different replication sets which are all active together, their intersection is used by the CDC publisher. This may be useful if these replication sets has some declarative customizations (see below).

This would be certainly valuable.

3) Different replication sets are declared as intended for different CDC plugins. This implies that multiple CDC plugins may be configured independently. In this cases the CDC publisher checks the source (table) against the target (plugin) before sending the changes.

This is certainly interesting. I can imagine a business case for a CDC plugin that does data stream processing instead persistence to some kind of replica.

Second, IMHO declaring tables as "publishable" via CREATE|ALTER TABLE is too restrictive. I'd rather manage the replication set using some global commands, be it ALTER DATABASE or something different, allowing to include/exclude all tables at once, or comma-separated list of tables, or maybe tables by mask (regexp?). Of course, both SQL solutions (database level and table level) may co-exist.

Agreed. However, would be database and table level definitions independent, or would we translate database level to batch of table ones? First would allow independent revocation but would complicate processing.

Finally, if we consider the replication set being a filter, it may be also useful to limit the published change set to some particular operations (INSERT|UPDATE|DELETE) or even some particular rows (WHERE filter). I doubt this is useful for replication per se, but this may allow something similar to "change views" in InterBase, currently with a CDC plugin acting as a client, but perhaps it could be extended later to interact with the real client application.

This would be certainly interesting. It would allow data sharding and all sorts of various interesting "utilizations" of replication plumbing for other things than just replication itself.

And one partially related question from another angle: does it make sense to implement also replica-side declarative filtering? I mean the case where changes for all tables are journaled but for some reason only some tables should be applied to replica - e.g. two independent replicas with different filters but replicated from the same master journal (to avoid double journaling). If this feature is desirable, then how should the master-side filter (replication set) co-exist with the replica-side filter?

It's tempting, but I see potential for problems. If we would allow multiple sets & filters at master node, there is no need to have them at replica. And if replica would have different definitions than master, then it's not possible to replace master with replica in recovery scenario. It could be an interim solution for absence of multiple sets & filters on master, but it would be hard to deprecate them once we implement such master solution.

regards
Pavel


Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Reply via email to