THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
When users disable tiered storage on a topic, the tiered storage state on a topic transitions through the following stages: ENABLED → DISABLING → DISABLED.
ENABLED
The ENABLED state represents when tiered storage is enabled on a topic or when it has been re-enabled after disablement. In this state, the RemoteLogManager (RLM) has scheduled a task for the topic-partitions with the RemoteLogManager thread pool and RemoteStorageFetcher thread pool. The possible state transition from the ENABLED state is to the DISABLING state.
DISABLING
When users initiate an alter config API call to disable tiered storage on a topic that is currently in the ENABLED state, the topic enters the DISABLING state. In this state, various tasks are performed asynchronously to complete the disablement process. These tasks include:
...
While the topic is in the DISABLING state, new alter config API calls to disable tiered storage will be rejected. The possible state transition from the DISABLING state is to the DISABLED state.
DISABLED
The DISABLED state represents when tiered storage is fully disabled on a topic. In this state, the RLM does not have any scheduled tasks for the topic-partitions in the RemoteLogManager thread pool for copying segments to remote storage. If the topic was disabled with the remote.log.disable.policy=delete option, all remote data is marked for deletion and it is inaccessible for read. If the topic was disabled with the remote.log.disable.policy=retain option, there will be tasks scheduled for the topic-partitions only for expiration of remote logs but not for copying logs to remote storage. The RemoteStorageFetcher thread pool will also continue to accept remote fetch requests. The possible state transition from DISABLED state is to the ENABLED.
Data Expiry
When tiered storage is enabled in a topic, there are two sets of retention configurations available: local retention configuration (local.retention.ms and/or local.retention.bytes ) and topic-wide retention configuration(retention.ms and/or retention.bytes ). For thetopic-wide retention configuration, if the values are not explicitly set, Kafka falls back to using the log.retention.ms and/or log.retention.bytes values.
When tiered storage is disabled on a topic, the local retention configuration becomes irrelevant, and all data expiration follows the topic-wide retention configuration exclusively.
If tiered storage is disabled using the remote.log.disable.policy=delete policy, the topic will not have any archived segments in remote storage. In this case, the topic-wide retention configuration operates similarly to any non-tiered storage topic.
On the other hand, if tiered storage is disabled with the remote.log.disable.policy=retain policy, it is possible that the topic still has segments in remote storage. In such scenarios, the topic-wide retention configuration will come into effect starting from the Remote log start offset (Rx).