On Thu, Nov 26, 2015 at 9:05 PM, liviuslivius liviuslivius@... [firebird-support] <firebird-support@yahoogroups.com> wrote:

 

hi,

modification datetime is not enaugh to replication. think about

1. transaction started and modify data

2. synchronization started and fetch data from last modifird datetime

3. synchronization end

4. transaction commit data from point 1 and store datetime before synch started

5. synchronization start and omit modification from point 1 because date is older

regards,

Karol Bieniaszewski

Pozdrawiam

-------- Oryginalna wiadomość --------
Od: "Slavomir Skopalik skopalik@... [firebird-support]" <firebird-support@yahoogroups.com>
Data: 26.11.2015 12:46 (GMT+01:00)
Do: firebird-support@yahoogroups.com
Temat: Re: [firebird-support] Replication SW experience

 

Hi Aldis,
more info about situation.

1. Normal operation
- Asynchronous replication will wait for DB Event and than
immediately start transfer.
All data changes will be logged by triggers into log table.

2. Disaster
Local production will continue works because have production plan and
records data into local DB.
When connection will be back all data will be synchronized.
There are no so much real possibilities to conflict.

Each table has UTC time stamp of last modification. In most cases,
latest wins.
Rest of conflict we have to program manually.

I have idea how to do it (it is nice work), but I don't want to invent
"wheel".

I'm looking on something like copycat, but web site is little bit confusing.

Any experience?

Slavek

Ing. Slavomir Skopalik
Executive Head
Elekt Labs s.r.o.
Collection and evaluation of data from machines and laboratories
by means of system MASA (http://www.elektlabs.cz/m2demo)
----------------------------------------------------------
Address:
Elekt Labs s.r.o.
Chaloupky 158
783 72 Velky Tynec
Czech Republic
----------------------------------------------------------
Mobile: +420 724 207 851
icq:199 118 333
skype:skopaliks
e-mail:skopalik@...
http://www.elektlabs.cz

On 26.11.2015 9:00, Alan J Davies Alan.Davies@...
[firebird-support] wrote:
> Hi Slavek, there are a number of issues you need to resolve before
> making a decision. If network performance is an issue then replication
> is not the answer - unless you can send the changes back to head office
> 'out of hours'. This means the different databases will be out of sync
> for some time. Is this acceptable from your customer's point of view?
> Are there different production plants making the same item? What happens
> if plant 1 and plant 2 make the same item on the same day?
>
> I think you may have to generate your own version because replication is
> not what you need (imho) but you could create a series of triggers and
> tables to do what you want. e.g. if you have a table called PARTS,
> create SYNC_PARTS and each time there is a change to PARTS you add a
> record. You could then send your updates to HO via a scheduled update or
> even within the same transaction if your network access allows for that.
>
> Alan J Davies
> Aldis
>
>
> On 25/11/2015 21:35, Slavomir Skopalik skopalik@...
> [firebird-support] wrote:
>> Hi all,
>> we are preparing new project with bidirectional replication.
>>
>> Customer idea is to have master database in head quoter
>> and slave databases on production plant (to solve network performance
>> and availability issues).
>>
>> Witch replication SW you can recommend for this bidirectional replication?
>> What is typical issues and weakness of this SW.
>>
>> Thank you.
>>
>> Slavek
>>
>> --
>> Ing. Slavomir Skopalik
>> Executive Head
>> Elekt Labs s.r.o.
>> Collection and evaluation of data from machines and laboratories
>> by means of system MASA (http://www.elektlabs.cz/m2demo)
>> ----------------------------------------------------------
>> Address:
>> Elekt Labs s.r.o.
>> Chaloupky 158
>> 783 72 Velky Tynec
>> Czech Republic
>> ----------------------------------------------------------
>> Mobile: +420 724 207 851
>> icq:199 118 333
>> skype:skopaliks
>> e-mail:skopalik@...
>> http://www.elektlabs.cz
>>
>>