firebird
firebird copied to clipboard
FirebirdSQL
Stricter replication configuration
It's been suggested to improve the way replication is configured. Currently, replication can be enabled at the database level and at the configuration level (both are required), but these settings are independent. The idea is to make configuration layered: first it should be enabled at the configuration level and then at the database level. If the order is reversed, error or warning should be raised and replication should not be enabled. This approach allows to control that no changes are missing the replica due to misconfiguration. For example, database is set up for replication properly but some other embedded connection is performed from another directory which uses its own replication.conf which has replication disabled. Currently all changes performed by that other connection will not be replicated, while DBA surely does not expect this. With the replication setting at the database level being mandatory, this erroneous situation may be detected, either immediately during connection time, or postponed until some writeable transaction is started.
It defines replication settings per database. I'd hate to have them moved to the DDL management.
"Alter database enable publication" is already at DDL level or you have something else on mind?
Replication (using the built-in implementation) is impossible without [at least] the configured paths (target connection string / journal directories). This is why we need configuration. Currently we check the database setting after checking the configuration file. If the database setting becomes primary, then configuration should be checked only if replication is known to be enabled in the database.
It sounds right but the check and throwing of error (not warning) should be done at actual replication time as well not just on DDL enabling publication.
What if server/embedded connections both enables replication, but each one going to different places?
@aafemt, If you enable publication, you usually want it to start immediately. But it simply cannot happen if configuration is missing, so what's the point? Moreover, if DBA enabled publication and forgot (or delayed) to configure it, users will not be able to write anything until DBA is back and fixed the issue. I'd rather prefer to make this error-prone and require pre-configuration.
@asfernandes, this would be PITA ;-) I suspect the most common situation for users would be to detect the error and run the embedded tool from the correct location (which has the correct configuration). Kinda "fixing" it by defining fake replication paths inside their local configuration looks like shooting themselves in the foot, so I wouldn't care. But of course it's possible that two instances are installed on the server and both are properly configured for replication and ISQL is wrongly run from a different FB root in the embedded mode. Of course, we may require that the first connection defines the replication settings (cache them in shmem), but it's not a 100% guarantee, the "guilty" ISQL may come while nobody else is connected. So far I don't see any easy solution for such case.
@aafemt, I seem to misunderstood your last suggestion. Of course, error will be thrown not only during enable DDL but also during write operations.
Maybe related: https://github.com/FirebirdSQL/firebird/issues/6260#issuecomment-925039361
