Re: [Firebird-devel] Cascade replication

[Dimitry Sibiryakov]

Pro Turm wrote 01.11.2021 15:21:
My goal is indeed replication without a single point of failure. It the above 
would have been possible (replication from two masters), than the following 
would also have been possible :

H would be a replica in the case when nothing else works anymore, A,B,D have 
failed
D->H is not necessary needed in this case


  If your goal is a high availability system then this schema is 
overcomplicated (and have problem with duplicating data flow).

  Let's consider architecture of a high availability system from the beginning:

  A system with single server A is dangerous. Its destruction leads to system 
unavailability and big data losses.
  A system of two servers with replication A->B is save. After destruction 
(failure) of single server the system is still available though reduced to 
dangerous mode. If failed server is A then there is small data losses*. You must 
rebuild the system ASAP.
  A system of three servers A->B->C (or A->B + A->C) is safe. After single 
failure it is still safe in 2 cases of 3 and you have more time to rebuild it.
  A system of four servers A->B-C + A->D is safe after any single failure and 
even a double failure may still keep it safe (for example if failed servers are 
D and C).
  A system of five servers A->B->C + A->D->E can be in danger only after a 
definite double failure (B and D).
  A system of six servers A->B->C + A->D->E + A->F is safe after any double 
failure.

  The bigger this snowflake grows the more safe it is.

  Extreme high availability can be provided by fully linked net, which stay 
available and safe after failure of every but two servers. Unfortunately this 
scheme is impossible with current built-in replication out-of-box (sophisticated 
log delivery system is required).


  *Small data losses are unavoidable with asynchronous replication which always 
have non-zero replication lag.


--
  WBR, SD.


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

Re: [Firebird-devel] Cascade replication

[Pro Turm]

>
> >
> > Is the following constellation also possible?
> > A--\  /--E
> > B---D-F
> > C--/  \--G
> > That is that D replicates A,B,C (which share the same content e.g.
> A-B-C)
> > and simultaneously D is s primary to E,F,G ?
>
I have no idea if it can work with built-in replication at all.
>
>In any case the scheme doesn't look robust because of single points of
> failure in D and F but perhaps it can be good for something else.
> Replication is
> used for a definite purpose, not just "because we can".

My goal is indeed replication without a single point of failure. It the
above would have been possible (replication from two masters), than the
following would also have been possible :
H would be a replica in the case when nothing else works anymore, A,B,D
have failed
D->H is not necessary needed in this case
[image: image.png]
How do the transaction logs are generated? Do they depend on the primary
guid? If not, that shall work...

Am Mo., 1. Nov. 2021 um 12:06 Uhr schrieb Dimitry Sibiryakov <
s...@ibphoenix.com>:

> Pro Turm wrote 01.11.2021 11:47:
> > Thanks. Could you please give some more words about this case?
> >
> > Is the following constellation also possible?
> > A--\  /--E
> > B---D-F
> > C--/  \--G
> > That is that D replicates A,B,C (which share the same content e.g.
> A-B-C)
> > and simultaneously D is s primary to E,F,G ?
>
>I have no idea if it can work with built-in replication at all.
>
>In any case the scheme doesn't look robust because of single points of
> failure in D and F but perhaps it can be good for something else.
> Replication is
> used for a definite purpose, not just "because we can".
>
> --
>WBR, SD.
>
>
> Firebird-Devel mailing list, web interface at
> https://lists.sourceforge.net/lists/listinfo/firebird-devel
>
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] Cascade replication

[Dimitry Sibiryakov]

Pro Turm wrote 01.11.2021 11:47:

Thanks. Could you please give some more words about this case?

Is the following constellation also possible?
A--\  /--E
B---D-F
C--/  \--G
That is that D replicates A,B,C (which share the same content e.g. A-B-C)
and simultaneously D is s primary to E,F,G ?


  I have no idea if it can work with built-in replication at all.

  In any case the scheme doesn't look robust because of single points of 
failure in D and F but perhaps it can be good for something else. Replication is 
used for a definite purpose, not just "because we can".


--
  WBR, SD.


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

Re: [Firebird-devel] Cascade replication

[Pro Turm]

Thanks. Could you please give some more words about this case?

> Is the following constellation also possible?
> A--\  /--E
> B---D-F
> C--/  \--G
> That is that D replicates A,B,C (which share the same content e.g. A-B-C)
> and simultaneously D is s primary to E,F,G ?
>

Am Do., 28. Okt. 2021 um 08:57 Uhr schrieb Pro Turm :

> > Which means cascading could be quite vulnerable. What is then the
>> quickest
>> > possible way to connect A to C in the above case?
>>
>>Drop database C, recreate replica from scratch.
>>
> Is the following constellation also possible?
> A--\   /--E
> B---D--F
> C--/   \--G
> That is that D replicates A,B,C (which share the same content) and
> simultaneously is s primary to E,F,G ?
>
>>
>> > > Restarting the servers: are there some performance issues
>> expected due to
>> > > restarting (looising data, long-time unavailability etc.) ?
>> >
>> > It depends.
>> >
>> > Could you please elaborate more on that ?
>>
>>Performance issues, data losses and recovery time highly depends on
>> the
>> nature of the disaster that has made the recovery needed, replication
>> settings
>> and other factors.
>
> Do you have more concrete measurements or cases? And some times (best,
> worst, average) according to the amount of data being replicated?
> Particularly I'm interested in asynchronous replication only.
>
> Am Mi., 27. Okt. 2021 um 14:49 Uhr schrieb Dimitry Sibiryakov <
> s...@ibphoenix.com>:
>
>> Pro Turm wrote 27.10.2021 14:39:
>> > Which means cascading could be quite vulnerable. What is then the
>> quickest
>> > possible way to connect A to C in the above case?
>>
>>Drop database C, recreate replica from scratch.
>>
>> > > Restarting the servers: are there some performance issues
>> expected due to
>> > > restarting (looising data, long-time unavailability etc.) ?
>> >
>> > It depends.
>> >
>> > Could you please elaborate more on that ?
>>
>>Performance issues, data losses and recovery time highly depends on
>> the
>> nature of the disaster that has made the recovery needed, replication
>> settings
>> and other factors.
>>
>> --
>>WBR, SD.
>>
>>
>> Firebird-Devel mailing list, web interface at
>> https://lists.sourceforge.net/lists/listinfo/firebird-devel
>>
>
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] Cascade replication

[Dimitry Sibiryakov]

Pro Turm wrote 01.11.2021 10:54:

    Drop database C, recreate replica from scratch.

could you please say what the recreation from scratch would look like according 
to your understanding ?


  Quoting README.replication:


## Creating the replica database

In the Beta 1 release, any physical copying method can be used:

* File-level copy when Firebird server is shutdown
* ALTER DATABASE BEGIN BACKUP + file-level copy + ALTER DATABASE END BACKUP
* nbackup -l + file-level copy + nbackup -n
* nbackup -b 0

Then the replica mode must be activated for the database copy. Two options are 
possible:

* gfix -replica read\_only database -- set up database as read-only 
replica
* gfix -replica read\_write database -- set up database as read-write 
replica



--
  WBR, SD.


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

Re: [Firebird-devel] Cascade replication

[Pro Turm]

>
> > Which means cascading could be quite vulnerable. What is then the
> quickest
> > possible way to connect A to C in the above case?
>
>Drop database C, recreate replica from scratch.
>
 Hallo,
could you please say what the recreation from scratch would look like
according to your understanding ?

Am Mi., 27. Okt. 2021 um 14:49 Uhr schrieb Dimitry Sibiryakov <
s...@ibphoenix.com>:

> Pro Turm wrote 27.10.2021 14:39:
> > Which means cascading could be quite vulnerable. What is then the
> quickest
> > possible way to connect A to C in the above case?
>
>Drop database C, recreate replica from scratch.
>
> > > Restarting the servers: are there some performance issues expected
> due to
> > > restarting (looising data, long-time unavailability etc.) ?
> >
> > It depends.
> >
> > Could you please elaborate more on that ?
>
>Performance issues, data losses and recovery time highly depends on the
> nature of the disaster that has made the recovery needed, replication
> settings
> and other factors.
>
> --
>WBR, SD.
>
>
> Firebird-Devel mailing list, web interface at
> https://lists.sourceforge.net/lists/listinfo/firebird-devel
>
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] Cascade replication

[Pro Turm]

>
> > Which means cascading could be quite vulnerable. What is then the
> quickest
> > possible way to connect A to C in the above case?
>
>Drop database C, recreate replica from scratch.
>
Is the following constellation also possible?
A--\   /--E
B---D--F
C--/   \--G
That is that D replicates A,B,C (which share the same content) and
simultaneously is s primary to E,F,G ?

>
> > > Restarting the servers: are there some performance issues expected
> due to
> > > restarting (looising data, long-time unavailability etc.) ?
> >
> > It depends.
> >
> > Could you please elaborate more on that ?
>
>Performance issues, data losses and recovery time highly depends on the
> nature of the disaster that has made the recovery needed, replication
> settings
> and other factors.

Do you have more concrete measurements or cases? And some times (best,
worst, average) according to the amount of data being replicated?
Particularly I'm interested in asynchronous replication only.

Am Mi., 27. Okt. 2021 um 14:49 Uhr schrieb Dimitry Sibiryakov <
s...@ibphoenix.com>:

> Pro Turm wrote 27.10.2021 14:39:
> > Which means cascading could be quite vulnerable. What is then the
> quickest
> > possible way to connect A to C in the above case?
>
>Drop database C, recreate replica from scratch.
>
> > > Restarting the servers: are there some performance issues expected
> due to
> > > restarting (looising data, long-time unavailability etc.) ?
> >
> > It depends.
> >
> > Could you please elaborate more on that ?
>
>Performance issues, data losses and recovery time highly depends on the
> nature of the disaster that has made the recovery needed, replication
> settings
> and other factors.
>
> --
>WBR, SD.
>
>
> Firebird-Devel mailing list, web interface at
> https://lists.sourceforge.net/lists/listinfo/firebird-devel
>
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] Cascade replication

[Dimitry Sibiryakov]

Pro Turm wrote 27.10.2021 14:46:

And how about the following constellation:


  The same. You still create a single failure point at B.

--
  WBR, SD.


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

Re: [Firebird-devel] Cascade replication

[Pro Turm]

>
> > How about the case A->B->C, and B fails?  Will A be replicating directly
> to C ?

And how about the following constellation:
A->B->C
...|->D
...|->F
i.e. B was originally replicating to C, D, F simultaneously, before it
failed. How could the replication from A to C, D, F simultaneously be
restored, i.e. is there any performance or other issues compared to the
case A->(B)->C ?


Am Mi., 27. Okt. 2021 um 14:39 Uhr schrieb Pro Turm :

> > How about the case A->B->C, and B fails?  Will A be replicating directly
>> to C ?
>>
>>No.
>>
> Which means cascading could be quite vulnerable. What is then the quickest
> possible way to connect A to C in the above case?
>
> > Restarting the servers: are there some performance issues expected due
>> to
>> > restarting (looising data, long-time unavailability etc.) ?
>>
>>It depends.
>>
> Could you please elaborate more on that ?
>
> Am Mi., 27. Okt. 2021 um 14:33 Uhr schrieb Dimitry Sibiryakov <
> s...@ibphoenix.com>:
>
>> Pro Turm wrote 27.10.2021 14:26:
>> > How about the case A->B->C, and B fails?  Will A be replicating
>> directly to C ?
>>
>>No.
>>
>> >   What does a switch from primary <-> replica mean? Only changing the
>> > configuration files?
>>
>>No, it is invoking "gfix" command with appropriate switches as
>> described in
>> README.replication.txt.
>>
>> > Restarting the servers: are there some performance issues expected due
>> to
>> > restarting (looising data, long-time unavailability etc.) ?
>>
>>It depends.
>>
>> --
>>WBR, SD.
>>
>>
>> Firebird-Devel mailing list, web interface at
>> https://lists.sourceforge.net/lists/listinfo/firebird-devel
>>
>
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] Cascade replication

[Dimitry Sibiryakov]

Pro Turm wrote 27.10.2021 14:39:
Which means cascading could be quite vulnerable. What is then the quickest 
possible way to connect A to C in the above case?


  Drop database C, recreate replica from scratch.

> Restarting the servers: are there some performance issues expected due to 
> restarting (looising data, long-time unavailability etc.) ?


    It depends.

Could you please elaborate more on that ?


  Performance issues, data losses and recovery time highly depends on the 
nature of the disaster that has made the recovery needed, replication settings 
and other factors.


--
  WBR, SD.


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

Re: [Firebird-devel] Cascade replication

[Pro Turm]

>
> > How about the case A->B->C, and B fails?  Will A be replicating directly
> to C ?
>
>No.
>
Which means cascading could be quite vulnerable. What is then the quickest
possible way to connect A to C in the above case?

> Restarting the servers: are there some performance issues expected due to
> > restarting (looising data, long-time unavailability etc.) ?
>
>It depends.
>
Could you please elaborate more on that ?

Am Mi., 27. Okt. 2021 um 14:33 Uhr schrieb Dimitry Sibiryakov <
s...@ibphoenix.com>:

> Pro Turm wrote 27.10.2021 14:26:
> > How about the case A->B->C, and B fails?  Will A be replicating directly
> to C ?
>
>No.
>
> >   What does a switch from primary <-> replica mean? Only changing the
> > configuration files?
>
>No, it is invoking "gfix" command with appropriate switches as
> described in
> README.replication.txt.
>
> > Restarting the servers: are there some performance issues expected due
> to
> > restarting (looising data, long-time unavailability etc.) ?
>
>It depends.
>
> --
>WBR, SD.
>
>
> Firebird-Devel mailing list, web interface at
> https://lists.sourceforge.net/lists/listinfo/firebird-devel
>
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] Cascade replication

[Dimitry Sibiryakov]

Pro Turm wrote 27.10.2021 14:26:

How about the case A->B->C, and B fails?  Will A be replicating directly to C ?


  No.

  What does a switch from primary <-> replica mean? Only changing the 
configuration files?


  No, it is invoking "gfix" command with appropriate switches as described in 
README.replication.txt.


Restarting the servers: are there some performance issues expected due to 
restarting (looising data, long-time unavailability etc.) ?


  It depends.

--
  WBR, SD.


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

Re: [Firebird-devel] Cascade replication

[Pro Turm]

>
> > e.g. in A->B->C, when A fails to become B->C ?
>
>It is already B->C, there is nothing to do.

How about the case A->B->C, and B fails?  Will A be replicating directly to
C ?

> Further, is it possible and how that from A->B->C the following happens
> A<-B->C ?
>

>
Switch A from primary mode to replica, switch B from replica mode to
> master,
> make corresponding changes in the configuration files, restart servers.
>
 What does a switch from primary <-> replica mean? Only changing the
configuration files?
Restarting the servers: are there some performance issues expected due to
restarting (looising data, long-time unavailability etc.) ?

Am Mi., 27. Okt. 2021 um 14:14 Uhr schrieb Dimitry Sibiryakov <
s...@ibphoenix.com>:

> Pro Turm wrote 27.10.2021 13:52:
> > Is it possible and how does a replica become primary at some point?
>
>As usual, changing of the replica mode of the database (if necessary at
> all).
> Read readme.replication.txt in doc folder.
>
> > e.g. in A->B->C, when A fails to become B->C ?
>
>It is already B->C, there is nothing to do.
>
> > Further, is it possible and how that from A->B->C the following happens
> A<-B->C ?
>
>Switch A from primary mode to replica, switch B from replica mode to
> master,
> make corresponding changes in the configuration files, restart servers.
>
>The main problem is in database and application design that has to be
> made
> with replication in mind at the beginning.
>
> --
>WBR, SD.
>
>
> Firebird-Devel mailing list, web interface at
> https://lists.sourceforge.net/lists/listinfo/firebird-devel
>
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] Cascade replication

[Dmitry Yemanov]

27.10.2021 14:52, Pro Turm wrote:

Is it possible and how does a replica become primary at some point?


It never does it by itself. Firebird provides replication, but 
high-availability cluster (which you're talking about) is way more than 
just replication. Custom automatization is required.



e.g. in A->B->C, when A fails to become B->C ?


In read-only replica, this is impossible, as all changes are produced by 
A and the whole chain stops working without A.
In read-write replica, the B->C part will continue working without A 
automagically. But you need somehow to reconnect everybody from A to B 
(and make sure A never reappears).


Further, is it possible and how that from A->B->C the following happens  
A<-B->C ?


Impossible without manual DBA actions.


Dmitry


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

Re: [Firebird-devel] Cascade replication

[Dimitry Sibiryakov]

Pro Turm wrote 27.10.2021 13:52:

Is it possible and how does a replica become primary at some point?


  As usual, changing of the replica mode of the database (if necessary at all). 
Read readme.replication.txt in doc folder.



e.g. in A->B->C, when A fails to become B->C ?


  It is already B->C, there is nothing to do.


Further, is it possible and how that from A->B->C the following happens  
A<-B->C ?


  Switch A from primary mode to replica, switch B from replica mode to master, 
make corresponding changes in the configuration files, restart servers.


  The main problem is in database and application design that has to be made 
with replication in mind at the beginning.


--
  WBR, SD.


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

Re: [Firebird-devel] Cascade replication

[Pro Turm]

Is it possible and how does a replica become primary at some point?

e.g. in A->B->C, when A fails to become B->C ?

Further, is it possible and how that from A->B->C the following happens
A<-B->C ?

Am Mi., 27. Okt. 2021 um 11:31 Uhr schrieb Dimitry Sibiryakov <
s...@ibphoenix.com>:

> Dmitry Yemanov wrote 27.10.2021 9:18:
> > Nope, it's configured on the replica side and allows the received
> changes to be
> > propagated further (if replica is also configured as a primary, i.e.
> A->B->C).
>
>...and must be disabled for replication A->B->A i.e. bidirectional to
> prevent
> infinite data bouncing.
>
> --
>WBR, SD.
>
>
> Firebird-Devel mailing list, web interface at
> https://lists.sourceforge.net/lists/listinfo/firebird-devel
>
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Re: [Firebird-devel] Cascade replication

[Dimitry Sibiryakov]

Dmitry Yemanov wrote 27.10.2021 9:18:
Nope, it's configured on the replica side and allows the received changes to be 
propagated further (if replica is also configured as a primary, i.e. A->B->C).


  ...and must be disabled for replication A->B->A i.e. bidirectional to prevent 
infinite data bouncing.


--
  WBR, SD.


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

Re: [Firebird-devel] Cascade replication

[Dmitry Yemanov]

27.10.2021 09:06, Karol Bieniaszewski wrote:


Can you point me

https://github.com/FirebirdSQL/firebird/commit/e6a33454e871b9f9a368ccf281081e867c2b18cf 



what is enabled here and on which side?

If i understand correctly it is configured on primary database side not 
on replica?


Nope, it's configured on the replica side and allows the received 
changes to be propagated further (if replica is also configured as a 
primary, i.e. A->B->C).



Dmitry


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

[Firebird-devel] Cascade replication

[Karol Bieniaszewski]

Hi

Can you point me 
https://github.com/FirebirdSQL/firebird/commit/e6a33454e871b9f9a368ccf281081e867c2b18cf

what is enabled here and on which side?
If i understand correctly it is configured on primary database side not on 
replica?
If yes, why it is needed? Why not „simple” configure another replication on 
replica side? And anothere on another replica side... It is more natural.
But maybe i am wrong here, please explain more this option.

regards,
Karol Bieniaszewski

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