Fwd: Data lost when using write-behind

[Denis Magda]

Igniters,

Do we queue changes on backup nodes as well and flush them to the store if a primary node leaves?

This is irrelevant for transactional caches since changes are queue and flushed on a side of a transaction initiator, right? And flushing from backups makes sense only for atomic caches, correct?

—
Denis

> Begin forwarded message:
>
> From: Shaomin Zhang <[hidden email]>
> Subject: RE: Data lost when using write-behind
> Date: April 18, 2016 at 6:35:20 PM GMT+3
> To: "[hidden email]" <[hidden email]>
> Reply-To: [hidden email]
>
> Hi Alexei
>  
> Will updates that are lost because of the node failure will be retried to be persisted to database later?
>  
> Thanks
>  
> Shaomin
>  
> From: Alexei Scherbakov [mailto:[hidden email]]
> Sent: 18 April 2016 15:27
> To: [hidden email]
> Subject: Re: Data lost when using write-behind
>  
> Hi,
>  
> You should use write-behind mode only if it's acceptable for you to lose some updates to persistent store on node failures.
> Be vary of possible desync between persistent store and cache after node recovery.
> You can tune write-behind behavior as described here:
> https://apacheignite.readme.io/docs/persistent-store#configuration <https://urldefense.proofpoint.com/v2/url?u=https-3A__apacheignite.readme.io_docs_persistent-2Dstore-23configuration&d=CwMFaQ&c=lcVbikor4usg5Rj5OmznbA&r=TO3grc1lvgRzUij7SCtFhBPVz_ocKy44E1ncA3VjNmM&m=vJJJDAQ260MnYql1raooH2qhXcGEeGtNVzdRirH_kzo&s=NxaNDHVKM3hIoqnL1tRaKHJIQcztibaLeIKSoiJfisM&e=>
>  
>  
>  
> 2016-04-18 5:25 GMT+03:00 wang shuai <[hidden email] <mailto:[hidden email]>>:
>   When testing the write-behind feature, I found the data which would be
> persisted to back-end database was put in a queue of JVM. That means if that
> server crash, the data which has not been persisted to the database will be
> lost. Even though that part of data can be found in other server's memory,
> that data can not be updated to database automatically.
>   So I want to make clear what the recommended scenario is to use
> write-behind and how to handle the server crash when using write-behind.
>
>
>
> --
> View this message in context: http://apache-ignite-users.70518.x6.nabble.com/Data-lost-when-using-write-behind-tp4265.html <https://urldefense.proofpoint.com/v2/url?u=http-3A__apache-2Dignite-2Dusers.70518.x6.nabble.com_Data-2Dlost-2Dwhen-2Dusing-2Dwrite-2Dbehind-2Dtp4265.html&d=CwMFaQ&c=lcVbikor4usg5Rj5OmznbA&r=TO3grc1lvgRzUij7SCtFhBPVz_ocKy44E1ncA3VjNmM&m=vJJJDAQ260MnYql1raooH2qhXcGEeGtNVzdRirH_kzo&s=4hEm13b3-E-vZ1QcqI35pBDphCxAvgb5RKbdsbFViVU&e=>
> Sent from the Apache Ignite Users mailing list archive at Nabble.com.
>
>
>  
> --
>
> Best regards,
> Alexei Scherbakov
> _________________________________________________________
>
> This email, its contents, and any attachments transmitted with it are intended only for the addressee(s) and may be confidential and legally privileged. We do not waive any confidentiality by misdelivery. If you have received this email in error, please notify the sender immediately and delete it. You should not copy it, forward it or otherwise use the contents, attachments or information in any way. Any liability for viruses is excluded to the fullest extent permitted by law.
>
> Tudor Capital Europe LLP (TCE) is authorised and regulated by The Financial Conduct Authority (the FCA). TCE is registered as a limited liability partnership in England and Wales No: OC340673 with its registered office at 10 New Burlington Street, London, W1S 3BE, United Kingdom
>

[Alexey Goncharuk]

Denis,

Updates are always queued on primary nodes when write-behind is enabled,
regardless of atomicity mode. This is required because otherwise updates
can be written to the database in a wrong order.

We did not queue database updates on backups because we did not have a
mechanism that would allow us to track which updates have been written to
the database and which are not. Now that we have a partition counter that
is already used in continuous queries failover, it can also be reused for
write-behind ACKs.

I thought we had a ticket for this. I will re-check if this is true, and
will create if it is not there yet.

[Denis Magda]

Alex,

Thanks for the explanation!

However in case of write-through mode there is a difference in transactional and atomic caches. In transactional mode data is committed from a transaction coordinator side while in atomic mode – from primary nodes. Is my understanding correct?

Denis

From: Alexey Goncharuk
Sent: Monday, April 18, 2016 21:23
To: [hidden email]; [hidden email]
Subject: Re: Data lost when using write-behind

Denis,

Updates are always queued on primary nodes when write-behind is enabled, regardless of atomicity mode. This is required because otherwise updates can be written to the database in a wrong order.

We did not queue database updates on backups because we did not have a mechanism that would allow us to track which updates have been written to the database and which are not. Now that we have a partition counter that is already used in continuous queries failover, it can also be reused for write-behind ACKs. 

I thought we had a ticket for this. I will re-check if this is true, and will create if it is not there yet.

[Alexey Goncharuk]

Yes, this is correct, if there is no write-behind, then in TRANSACTIONAL
cache the database write happens from the originating node, and in ATOMIC
cache - from primary nodes.​

[Shaomin Zhang]

When the primary crashes, does Ignite emit any event about that? is the sessionEnd() method still going to be called?

Thanks

Shaomin

From: Alexey Goncharuk [mailto:[hidden email]]
Sent: 18 April 2016 23:55
To: [hidden email]; [hidden email]
Subject: Re: Data lost when using write-behind

Yes, this is correct, if there is no write-behind, then in TRANSACTIONAL cache the database write happens from the originating node, and in ATOMIC cache - from primary nodes.​

_________________________________________________________

This email, its contents, and any attachments transmitted with it are intended only for the addressee(s) and may be confidential and legally privileged. We do not waive any confidentiality by misdelivery. If you have received this email in error, please notify the sender immediately and delete it. You should not copy it, forward it or otherwise use the contents, attachments or information in any way. Any liability for viruses is excluded to the fullest extent permitted by law.

Tudor Capital Europe LLP (TCE) is authorised and regulated by The Financial Conduct Authority (the FCA). TCE is registered as a limited liability partnership in England and Wales No: OC340673 with its registered office at 10 New Burlington Street, London, W1S 3BE, United Kingdom