Hi,
Dne 21. 02. 19 v 11:15 Dimitry Sibiryakov napsal(a):
21.02.2019 10:46, Pavel Cisar wrote:
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.
Yes, if you limit usage of replica to standby/backup. But imagine
kind of sharding when some tables are replicated in one database and
others - to different one.
It's not about the use case (sharding etc.) but about distribution of
filters. We could have them either at master or at replica. If they
would be at master, there is IMHO no much point to have them also at
replica. Having master sets copied over to replica would allow easy
standby solutions that could be harder to have if these would not be the
same at both sides. Supporting filters at replica is IMHO only interim
solution for sharding while multiple sets and filters are not supported
at master. So I'd rather have all such multiple sets and filters at
master (copied over to replicas) where they could be more easily managed
than having different ones scattered all around. That way we could have
both, sharding and standby in one shot and much trouble.
regards
Pavel
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
