Ok,
Thanks for your help
On Thu, Feb 25, 2021 at 2:47 PM Dmitry Yemanov wrote:
> 25.02.2021 20:37, Lucas Schatz wrote:
>
> > So I guess that for now the "safest" option is async (related to network
> > instability) , correct?
>
> Right.
>
> > Just a curiosity, is it possible right now to enable
25.02.2021 20:37, Lucas Schatz wrote:
So I guess that for now the "safest" option is async (related to network
instability) , correct?
Right.
Just a curiosity, is it possible right now to enable a multiple replica
system in async mode, by defining multiple log_archive_directory?
If not, I
So I guess that for now the "safest" option is async (related to network
instability) , correct?
Just a curiosity, is it possible right now to enable a multiple replica
system in async mode, by defining multiple log_archive_directory?
If not, I guess that I can do it by changing
25.02.2021 17:10, Lucas Schatz wrote:
I im testing for a week, and I think that the current Synchronous mode
is awesome but too fragile to a daily use as a security feature, if I'm
not mistaken at any network failure or replica restart you'll be prone
to inconsistency in the replica data,
25.02.2021 16:45, Dmitry Yemanov wrote:
AFAIK replication server resend transactions using control files, replication sequence
and DB UUID received from INF call. INF call for remote database is ok, control files
can be in local FS as normally and replication packet is sent through IReplicator
25.02.2021 17:27, Dimitry Sibiryakov wrote:
AFAIK replication server resend transactions using control files,
replication sequence and DB UUID received from INF call. INF call for
remote database is ok, control files can be in local FS as normally and
replication packet is sent through
25.02.2021 15:18, Dmitry Yemanov wrote:
I mean write journals on master side and then apply them from master side directly to
remote replica database when it is available.
Again, we'll need to track the oldest segment marker -- from where to resend (and what can
be deleted).
AFAIK
25.02.2021 15:40, Dimitry Sibiryakov wrote:
I mean write journals on master side and then apply them from master
side directly to remote replica database when it is available.
Again, we'll need to track the oldest segment marker -- from where to
resend (and what can be deleted).
Dmitry
I im testing for a week, and I think that the current Synchronous mode is
awesome but too fragile to a daily use as a security feature, if I'm not
mistaken at any network failure or replica restart you'll be prone to
inconsistency in the replica data, leading to more work from de DBA to find
and
25.02.2021 13:36, Dmitry Yemanov wrote:
If you had something different in mind, please explain better.
I mean write journals on master side and then apply them from master side directly to
remote replica database when it is available. Synchronous replication cannot do that.
--
WBR, SD.
25.02.2021 15:07, Dimitry Sibiryakov wrote:
25.02.2021 13:04, Dmitry Yemanov wrote:
25.02.2021 13:39, Dimitry Sibiryakov wrote:
Is there option to set "database = inet://remote:database" in
replication.conf for a replica?
Nope. Something like that is considered for future versions.
But
25.02.2021 13:04, Dmitry Yemanov wrote:
25.02.2021 13:39, Dimitry Sibiryakov wrote:
Is there option to set "database = inet://remote:database" in replication.conf for a
replica?
Nope. Something like that is considered for future versions.
But network protocol has support for IReplicator
25.02.2021 13:39, Dimitry Sibiryakov wrote:
Is there option to set "database = inet://remote:database" in
replication.conf for a replica?
Nope. Something like that is considered for future versions.
Dmitry
Firebird-Devel mailing list, web interface at
25.02.2021 09:41, Dmitry Yemanov wrote:
How do you setup async replication if the replica is on a different Firebird Server? Do
you have to have an external process copying journal files to replica server? If so,
which files need copying and to which folder(s)? or, can set up log_directory to
25.02.2021 09:27, Peter Gore wrote:
Your suggestion still did not work. What _does _seem to work is if I
make log_source_directory = log_directory (NOT log_archive_directory as
advised). *Please comment*.
This is wrong.
I am getting errors however in the replication log
TOSHPJG (replica)
Hi Dimetri,
3 things if I may
Your suggestion still did not work. What *does *seem to work is if I make
log_source_directory = log_directory (NOT log_archive_directory as
advised). *Please comment*.
I am getting errors however in the replication log
TOSHPJG (replica) Thu Feb 25 06:11:39 2021
Hi Dimitry,
At least now I do have a replication log - for the first time. It contains
one entry.
TOSHPJG (replica) Wed Feb 24 06:26:05 2021
Database: D:\USERS\PETER\DOCUMENTS\FB4DATA\FB4TESTREPLICA.FDB
WARNING: Record being deleted from table INIDB does not exist, ignoring
Not sure if this is
24.02.2021 09:52, Peter Gore wrote:
database = D:\Users\Peter\Documents\FB4Data\FB4TEST.FDB
{
log_directory = D:\Apps\FB4\FB4Test\chlog
log_archive_directory = D:\Apps\FB4\FB4Test\archlog
log_archive_timeout = 10
}
database = D:\Users\Peter\Documents\FB4Data\FB4TESTReplica.FDB
{
Hi Dimitry,
Thank you for your assistance so far. I have got synchronous replication
working fine but still no joy with asynchronous. Here's my Replication.conf
database = D:\Users\Peter\Documents\FB4Data\FB4TEST.FDB
{
log_directory = D:\Apps\FB4\FB4Test\chlog
log_archive_directory =
On 23-02-2021 07:31, Peter Gore wrote:
Good morning, I'm a long standing Firebird User since FB1.5! My interest
in FB4 is primarily replication, which I have been unable to get
working. I have also noticed some errors in the documentation that I
note below.
I have manually downloaded the
23.02.2021 12:30, Mark Rotteveel wrote:
Dmitry, your push with the change was a bit messy
Yes, I've noticed that :-(
could you rebase
before pushing if your local master diverges from the remote master.
Forgot about that, sorry.
Dmitry
Firebird-Devel mailing list, web interface at
On 2021-02-23 07:48, Dmitry Yemanov wrote:
23.02.2021 09:31, Peter Gore wrote:
I also ran all the necessary DDL statements and run GFIX as prescribed
*GFIX - Doc anomaly 2*
Release Notes
I found empirically that
Page 28
gfix -replica read-only
should be
gfix -replica
23.02.2021 11:57, Peter Gore wrote:
Here's my new config
database = D:\Users\Peter\Documents\FB4Data\FB4TEST.FDB
{
log_directory = D:\Apps\FB4\FB4Test\chlog
log_archive_directory = D:\Apps\FB4\FB4Test\archlog
log_archive_timeout = 10
verbose_logging = true
}
database =
Thanks Dimitry for the super fast response. Yes you were correct the paths
were incorrect. I have corrected this and no longer get the error
message. Its still not replicating though.
Here's my new config
database = D:\Users\Peter\Documents\FB4Data\FB4TEST.FDB
{
log_directory =
23.02.2021 09:31, Peter Gore wrote:
As a test I have tried to get asynchronous replication working. Is this
even possible when Master and Replica is on the same Server?
Sure. Even using a single FB instance for both.
I have two
databases; FB4Test.fdb and FB4TestReplica.fdb o the same
Good morning, I'm a long standing Firebird User since FB1.5! My interest in
FB4 is primarily replication, which I have been unable to get working. I
have also noticed some errors in the documentation that I note below.
I have manually downloaded the 32bit version and and run it as an
application
26 matches
Mail list logo
