Details
-
New Feature
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
None
-
None
Description
1) WAL should be disabled by custom discovery message
- without triggering exchange,
- without triggering checkpoint (since it's non recoverable case)
In case someone is trying to disable already disabled WAL he should be notified that WAL already disabled
Only cachegroups containing one cache can de disabled
2) WAL should be prepared to be enabled by custom discovery message with
- triggering exchange,
- disabling cache proxies,
- waiting for checkpoints at every node.
In case someone is trying to enable already enablling WAL he should be notified that enabling in progress.
3) WAL should be enabled by custom discovery message
- without triggering exchange
but - with enabling proxies
once all nodes finished their checkpoints.
Failover:
On any failure during loading (while WAL disabled or enabling) we should be able to reactivate cluster without affected caches content.
Originating node fail should be covered (at WAL disabled and enabling cases)
API:
Public API should be located at IgniteCluster
Attachments
Issue Links
- Blocked
-
IGNITE-7004 Ability to disable WAL (Cross-cache tx should be rescricted while WAL disabled)
- Open
- is related to
-
IGNITE-8948 Allow checking of LOGGING status via SQL/JDBC
- Open
- relates to
-
IGNITE-7495 Ability to disable WAL globally for data region
- Open
-
IGNITE-7004 Ability to disable WAL (Cross-cache tx should be rescricted while WAL disabled)
- Open
-
IGNITE-7005 Ability to disable WAL (Recoverable case)
- Open
-
IGNITE-7494 WAL management commands for control.sh script
- Open
-
IGNITE-7493 .NET: Propagate WAL management API
- Resolved
-
IGNITE-7415 Ability to disable WAL (Documentation)
- Closed
- links to