[ 
https://issues.apache.org/jira/browse/IGNITE-6411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16218423#comment-16218423
 ] 

Vladimir Ozerov commented on IGNITE-6411:
-----------------------------------------

[~agoncharuk], [~avinogradov], [~dsetrakyan], following our conversations, here 
is design proposal.

1) Stage 1 - base implementation
1.1) WAL status is changed through custom discovery message
1.2) WAL disable triggers exchange and increases minor topology version, then 
changes the state and triggers checkpoint, but do not wait for it to complete
1.3) WAL enable does the same, but do wait for checkpoint to finish. During 
this checkpoint none updates to cache are allowed
1.4) WAL can be disabled either globally or on per-cache-group basis
1.5) If node crashed in disabled WAL mode, we should cleanup all data for 
affected cache group to avoid inconsistent state
1.6) Cross-cache transactions affecting caches with different modes (e.g. one 
enabled, another disabled) are not allowed
1.7) Native public API - to be defined separately

2) Stage 2 - advanced features
2.1) Optimization: no copy-on-write during checkpoint for WAL-disabled caches
2.2) If node crashed in disabled WAL mode instead of cleaning all the data, we 
can recover to the state before WAL was disabled
2.3) Advanced API: REST, JDBC, ODBC, control.sh
2.4) Advanced security - it should be able to control who can disabled WAL as 
this is dangerous operation.


> Add ability to disable WAL for ceratin caches in runtime
> --------------------------------------------------------
>
>                 Key: IGNITE-6411
>                 URL: https://issues.apache.org/jira/browse/IGNITE-6411
>             Project: Ignite
>          Issue Type: Task
>          Components: persistence
>    Affects Versions: 2.1
>            Reporter: Vladimir Ozerov
>            Assignee: Anton Vinogradov
>              Labels: iep-1, performance
>
> Currently every cache update require write to WAL. When doing bulk data load 
> usually crash recovery is not needed. If something went wrong during data 
> load, we should simply purge all intermediate data on cache restart.
> It makes sense to add ability to disable WAL for ceratin caches. Depending on 
> restrictions of current architecture, it could be done on per-cache, 
> per-cache-group or per-memory-policy level.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to