MySQL Shell 8.0
In MySQL 8, the binary log is automatically purged (as defined
by binlog_expire_logs_seconds
).
This means that a cluster which has been running for a longer
time than
binlog_expire_logs_seconds
could eventually not contain an instance with a complete binary
log that contains all of the transactions applied by the
instances. This could result in instances needing to be
provisioned automatically, for example using MySQL Enterprise Backup, before they
could join the cluster. Instances running 8.0.17 and later
support the MySQL Clone plugin, which resolves this issue by
providing an automatic provisioning solution which does not rely
on incremental recovery, see
Section 7.4.6, “Using MySQL Clone with InnoDB Cluster”.
Instances running a version earlier than 8.0.17 only support
incremental recovery, and the result is that, depending on which
version of MySQL the instance is running, instances might have
to be provisioned automatically. Otherwise operations which rely
on distributed recovery, such as
and so on might fail.
Cluster
.addInstance()
On instances running earlier versions of MySQL the following rules are used for binary log purging:
Instances running a version earlier than 8.0.1 have no
automatic binary log purging because the default value of
expire_logs_days
is 0.
Instances running a version later than 8.0.1 but earlier
than 8.0.4 purge the binary log after 30 days because the
default value of
expire_logs_days
is 30.
Instances running a version later than 8.0.10 purge the
binary log after 30 days because the default value of
binlog_expire_logs_seconds
is 2592000 and the default value of
expire_logs_days
is 0.
Thus, depending on how long the cluster has been running binary logs could have been purged and you might have to provision instances manually. Similarly, if you manually purged binary logs you could encounter the same situation. Therefore you are strongly advised to upgrade to a version of MySQL later than 8.0.17 to take full advantage of the automatic provisioning provided by MySQL Clone for distributed recovery, and to minimize downtime while provisioning instances for your InnoDB Cluster.