I got error while trying to add new 2 disks into 2 nodes
$minio server http://172.16.233.130/mnt/storage4/data http://172.16.233.130/mnt/storage3/data \
http://172.16.233.130/mnt/storage1/data http://172.16.233.130/mnt/storage2/data \
http://172.16.233.129/mnt/storage1/data http://172.16.233.129/mnt/storage2/data \
http://172.16.233.129/mnt/storage3/data http://172.16.233.129/mnt/storage4/data
FATA[0001] formatting storage disks failed cause=Number of disks 8 did not match the backend format 4 source=[server-main.go:466:serverMain()]
@huytn this is not an issue.
The disc is formatted for 4 node setup in current setup of yours.
Now if you have to run 8 disc/node setup you will need to make a fresh saperate distributed setup.
Additionally if you need to migrate objects from existing 4 disc setup to newer 8 disc installation, you can use mc mirror
Hope it helps.
@huytn - Minio in this case is working as intended, minio cannot be expanded or shrinkable in this manner. Minio is different by design. It is designed to solve all the needs of a single tenant. Spinning minio per tenant is the job of external orchestration layer. Any addition and removal means one has to rebalance the nodes. When Minio does it internally, it behaves like blackbox. It also adds significant complexity to Minio. Minio is designed to be deployed once and forgotten. We dont even want users to be replacing failed drives and nodes. Erasure code has enough redundancy built it. By the time half the nodes or drives are gone, it is time to refresh all the hardware. If the user still requires rebalancing, one can always start a new minio server on the same system on a different port and simply migrate the data over. It is essentially what minio would do internally. Doing it externally means more control and visibility. Minio is meant to be deployed in static units per tenant.
@koolhead17 @harshavardhana thanks you all
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Most helpful comment
@huytn - Minio in this case is working as intended, minio cannot be expanded or shrinkable in this manner. Minio is different by design. It is designed to solve all the needs of a single tenant. Spinning minio per tenant is the job of external orchestration layer. Any addition and removal means one has to rebalance the nodes. When Minio does it internally, it behaves like blackbox. It also adds significant complexity to Minio. Minio is designed to be deployed once and forgotten. We dont even want users to be replacing failed drives and nodes. Erasure code has enough redundancy built it. By the time half the nodes or drives are gone, it is time to refresh all the hardware. If the user still requires rebalancing, one can always start a new minio server on the same system on a different port and simply migrate the data over. It is essentially what minio would do internally. Doing it externally means more control and visibility. Minio is meant to be deployed in static units per tenant.