On 6/2/22 10:14, Ilya Eremin wrote:
Hello!
The last tablespaces proposal says:
> Tablespaces are excluded from replication because it's physical layout
> of a database and a replica may have another one.
which means that tablespaces-related DDL operators won't be executed
on a replica. But some conflicts may happen, for example, when a table
is being moved to another tablespace via ALTER TABLE SET TABLESPACE.
ALTER TABLE SET TABLESPACE is tablespaces-related DDL operator - i.e. it
should not be executed on replica. Why conflict?
If the tablespace doesn't exist in a replica, the statement will fail.
The tablespace should be created in a replica before the statement is
executed.
It is possible to do it in another way: replicate tablespaces-related
DDL to have the same set of tablespaces in a replica. The main problem
here is the path to a tablespace file. It still can be absolute (will
work if the path is also valid for a replica) or relative. It might be
helpful to use directory aliases which can be set in some
configuration file. And this is a downside - need to edit the
configuration file on a replica(s).
I do not think that such need is too big trouble. When one wants to
combine replication and tablespaces that does require some efforts,
including configuration.
Which way is better for default behaviour? Would be good to hear
opinions on this.
Ideally use of tablespaces in replication should be configurable. One
wants to quickly setup replica and forget about configuration issues,
other wants to have exact copy including tablespaces. Someone else may
use on replica another tablespaces set in order to optimize performance
in different way from master database. Why force everyone to go same way?
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
