<p>By default, Kafka server will not enable tiered storage feature. <code>remote.log.storage.system.enable</code>
is the property to control whether to enable tiered storage functionality in a broker or not. Setting it to "true" enables this feature.
</p>
<p><code>RemoteStorageManager</code> is an interface to provide the lifecycle of remote log segments and indexes. Kafka server
doesn't provide out-of-the-box implementation of RemoteStorageManager. Configuring <code>remote.log.storage.manager.class.name</code>
and <code>remote.log.storage.manager.class.path</code> to specify the implementation of RemoteStorageManager.
</p>
<p><code>RemoteLogMetadataManager</code> is an interface to provide the lifecycle of metadata about remote log segments with strongly consistent semantics.
By default, Kafka provides an implementation with storage as an internal topic. This implementation can be changed by configuring
<code>remote.log.metadata.manager.class.name</code> and <code>remote.log.metadata.manager.class.path</code>.
When adopting the default kafka internal topic based implementation, <code>remote.log.metadata.manager.listener.name</code>
is a mandatory property to specify which listener the clients created by the default RemoteLogMetadataManager implementation.
<p>After correctly configuring broker side configurations for tiered storage feature, there are still configurations in topic level needed to be set.
<code>remote.storage.enable</code> is the switch to determine if a topic wants to use tiered storage or not. By default it is set to false.
After enabling <code>remote.storage.enable</code> property, the next thing to consider is the log retention.
When tiered storage is enabled for a topic, there are 2 additional log retention configurations to set:
<ul>
<li><code>local.retention.ms</code></li>
<li><code>retention.ms</code></li>
<li><code>local.retention.bytes</code></li>
<li><code>retention.bytes</code></li>
</ul>
The configuration prefixed with <code>local</code> are to specify the time/size the "local" log file can accept before moving to remote storage, and then get deleted.
If unset, The value in <code>retention.ms</code> and <code>retention.bytes</code> will be used.
<p>While the early access release of Tiered Storage offers the opportunity to try out this new feature, it is important to be aware of the following limitations:
<ul>
<li>No support for clusters with multiple log directories (i.e. JBOD feature)</li>
<li>No support for compacted topics</li>
<li>Cannot disable tiered storage at the topic level</li>
<li>Deleting tiered storage enabled topics is required before disabling tiered storage at the broker level</li>
<li>Admin actions related to tiered storage feature are only supported on clients from version 3.0 onwards</li>
</ul>
</p>
<p>For more information, please check <ahref="https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Tiered+Storage+Early+Access+Release+Notes">Tiered Storage Early Access Release Note</a>.
property. If upgrading from 3.0.x or earlier, it may be necessary to set this property to <code>false</code>; see the property's
<ahref="#mirror_connector_replication.policy.internal.topic.separator.enabled">documentation</a> for more details.</li>
<li>Early access of tiered storage feature is available, and it is not recommended for use in production environments.
Welcome to test it and provide any feedback to us.
For more information about the early access tiered storage feature, please check <ahref="https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage">KIP-405</a> and
<ahref="https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Tiered+Storage+Early+Access+Release+Notes">Tiered Storage Early Access Release Note</a>.
</li>
</ul>
<h4><aid="upgrade_3_5_0"href="#upgrade_3_5_0">Upgrading to 3.5.0 from any version 0.8.x through 3.4.x</a></h4>