Core Concepts
Table of Contents
Erasure Coding
MinIO Erasure Coding is a data redundancy and availability feature that allows MinIO deployments to automatically reconstruct objects on-the-fly despite the loss of multiple drives or nodes in the cluster. Erasure Coding provides object-level healing with less overhead than adjacent technologies such as RAID or replication.
Erasure Coding splits objects into data and parity blocks, where parity blocks
support reconstruction of missing or corrupted data blocks. MinIO distributes
both data and parity blocks across minio server
nodes and
drives in an Erasure Set. Depending on the
configured parity, number of nodes, and number of drives per node in the Erasure
Set, MinIO can tolerate the loss of up to half (N/2
) of drives and still
retrieve stored objects.
The following table lists the outcome of varying EC levels on a MinIO Tenant with a single 16-drive server pool:
Since parity blocks require storage space, higher levels of parity provide increased tolerance to drive or pod failure at the cost of total usable storage capacity.
MinIO supports two parity levels: Standard (default) and Reduced. The default parity levels for a Tenant depends on the MinIO version deployed on that Tenant:
For MinIO version RELEASE.2021-01-30T00-20-58Z and later, the default standard
EC
depends on the number of volumes in the erasure set:For 8 or more volumes,
EC:4
For 6-7 volumes,
EC:3
For 4-5 volumes,
EC:2
For MinIO version RELEASE.2021-01-16T02-19-44Z or earlier, the default
EC
is 1/2 the drives in the erasure set. For example, a 16-drive server pool hasEC:8
.
You can set a custom erasure code parity setting by specifying the
MINIO_STORAGE_CLASS_STANDARD
and
MINIO_STORAGE_CLASS_REDUCED
environment variables for
standard and reduced parity respectively. Use the
env to specify the environment variables as part of
the MinIO Tenant YAML
specification prior to creating the Tenant.
For more complete documentation on erasure coding, see Erasure Coding.
Bucket Versioning
MinIO supports keeping multiple “versions” of an object in a single bucket. Write operations which would normally overwrite an existing object instead result in the creation of a new versioned object. MinIO versioning protects from unintended overwrites and deletions while providing support for “undoing” a write operation. Bucket versioning also supports retention and archive policies.
MinIO generates a unique immutable ID for each object. If a PUT request contains an object name which duplicates an existing object, MinIO does not overwrite the “older” object. Instead, MinIO retains all object versions while considering the most recently written “version” of the object as “latest”. Applications retrieve the latest object version by default, but may retrieve any other version in the history of that object.
You can enable or disable bucket versioning at any time using the
mc version enable
command. See
Bucket Versioning for more complete documentation.