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)
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 b
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
https://lists.sourceforge.net/lists/l
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 so
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 netw
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.
Hi *,
for the unique constraint the times are equivalent if the UTC time is
equivalent. How's this going to be handled when some timezone region changes
its offset and the UTC time becomes the same?
--
Mgr. Jiří Činčura
https://www.tabsoverspaces.com/
Firebird-Devel mailing list, web interfa
On 2021-02-25 13:52, Jiří Činčura wrote:
Hi *,
for the unique constraint the times are equivalent if the UTC time is
equivalent. How's this going to be handled when some timezone region
changes its offset and the UTC time becomes the same?
The value stored is in UTC and remains in UTC, so time
Firebird server stops to listen to new connections after error in nbackup
service
-
Key: CORE-6498
URL: http://tracker.firebirdsql.org/browse/CORE-6498
Project: Firebird
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 fi
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
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 replica
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 IReplic
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 t
Hardware-enforced Stack Protection might be something to enable in a
next Firebird:
https://techcommunity.microsoft.com/t5/windows-kernel-internals/developer-guidance-for-hardware-enforced-stack-protection/ba-p/2163340
--
Mark Rotteveel
Firebird-Devel mailing list, web interface at
https://li
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, lead
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 log_archive_comman
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 gu
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
> Could you describe the scenario you're thinking of that you think could
> be problematic.
Well, I was mostly thinking what would happen is suddenly some dates become
colliding in UTC in i.e. unique index and you rebuild the index. It was fine
before, but it's not now.
But it could be also so
On 2021-02-25 19:55, Jiří Činčura wrote:
Could you describe the scenario you're thinking of that you think
could
be problematic.
Well, I was mostly thinking what would happen is suddenly some dates
become colliding in UTC in i.e. unique index and you rebuild the
index. It was fine before, but
> If you rebuild the index, there will be no such problem, because the
> date is stored in UTC, so that will not have changed.
Yeah, silly me. Obviously the timezone info isn't lost when converting to UTC
and storing in index. What was I thinking??? 🤷♂️
--
Mgr. Jiří Činčura
https://www.tabsov
22 matches
Mail list logo
