[DISCUSSION] Transactional cache could be in inconsistent state after node recovery.

[Zhenya Stanilovsky]

Igniters, as previously was found [1] in some cases transactional cache can contain unexpected data after node crash and further recovery. Short explanation: it`s all due to ignite does not save transactional records into the WAL.
The simplest example: 1 node cluster and transactional cache, if crash has occurred during transaction processing data records will be partially stored into the wal and further recovery procedure will apply them, as is, thus if transaction contain keys [k1, k2, k3] after recovery we can obtain only [k1, k2], of course this is unexpected and erroneous behavior. There are numerous variants with multi nodes on how they can obtain inconsistent data after recovery [2]. PR [1] (already merged into master) has changed this situation and i suggest to turn on by default transactional records storing and remove flag  IGNITE_WAL_LOG_TX_RECORDS at all.
I benchmarked (attached in issue) and found no potential slowdowns here.
Any comments ? Review is appreciated too. Thanks!
 
[1]  https://issues.apache.org/jira/browse/IGNITE-6324
[2]  https://github.com/apache/ignite/pull/8987/files#diff-96ba20321a66ec20d0df55abcdeb0808ff6dd1d4b87b782c892496369321a593R75
[3]  https://issues.apache.org/jira/browse/IGNITE-14739
 
 
 
 

[Ivan Daschinsky]

As for me, it is logical to remove this flag after merging
IGNITE-6324. I suppose that the slowdown is negligible. BTW, yardstick
reports contains no information about confidence interval. I suppose
that another run could show not drop but improvement :)

пн, 24 мая 2021 г. в 12:06, Zhenya Stanilovsky <[hidden email]>:

>
>
> Igniters, as previously was found [1] in some cases transactional cache can contain unexpected data after node crash and further recovery. Short explanation: it`s all due to ignite does not save transactional records into the WAL.
> The simplest example: 1 node cluster and transactional cache, if crash has occurred during transaction processing data records will be partially stored into the wal and further recovery procedure will apply them, as is, thus if transaction contain keys [k1, k2, k3] after recovery we can obtain only [k1, k2], of course this is unexpected and erroneous behavior. There are numerous variants with multi nodes on how they can obtain inconsistent data after recovery [2]. PR [1] (already merged into master) has changed this situation and i suggest to turn on by default transactional records storing and remove flag  IGNITE_WAL_LOG_TX_RECORDS at all.
> I benchmarked (attached in issue) and found no potential slowdowns here.
> Any comments ? Review is appreciated too. Thanks!
>
> [1]  https://issues.apache.org/jira/browse/IGNITE-6324
> [2]  https://github.com/apache/ignite/pull/8987/files#diff-96ba20321a66ec20d0df55abcdeb0808ff6dd1d4b87b782c892496369321a593R75
> [3]  https://issues.apache.org/jira/browse/IGNITE-14739
>
>
>
>

--
Sincerely yours, Ivan Daschinskiy