On Wed, Feb 8, 2023 at 5:33 AM Peter J. Holzer <hjp-pgsql@xxxxxx> wrote:
On 2023-02-08 14:48:03 +0530, veem v wrote:
> So wanted to know from experts here, is there really exists any scenario in
> which UUID really cant be avoided?
Probably not. The question is usually not "is this possible" but "does
this meet the requirements at acceptable cost".
> Sequence Number = n*d+m+offset. Where n is the sequence order number, d is the
> dimensions of the multi-master replication, m ranges from 0 to n-1 is the
> number assigned to each node in the replication, and offset is the number to
> offset the sequence numbers.
Yes, you can do this. In fact, people (including me) have already done
this.
But it's relatively easy to mess this up:
Firstly, you have to make sure that d is larger than your number of
(active) replicas will ever be, but still small enough that you will
never overflow. Probably not a problem with 64 bit sequences (if you set
d to 1E6, you can still count to 9E12 on each node), but might be a
problem if you are for some reason limited to 32 bits.
Secondly (and IMHO more importantly) you have to make sure each node
gets its own unique offset. So this needs to be ensured during
deployment, but also during migrations, restores from backups and other
infrequent events.
?? All you have to do is ensure each node has its own unique id, and that id is involved in sequence generation. This has to be done for other reasons than id generation, and is a zero effort/risk process.
The id would then contain the identifier of the node that generated the id, rather than the node that contains the id. This is exactly analogous to strategies that use mac# as part of id prefix for example. Once generated, it's known unique and you don't have to consider anything. This is exactly what I do, and there is no interaction with backups, deployments, migrations, etc. Node expansion does require that each node requires a unique node id, and that's it.
merlin
