THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
(If the community disagrees and wants Solr releases to support creation of both types of backups simultaneously, the existing "repository" API parameter can be used to disambiguate the type of backup to be created.)
Example (assumes SIP is completed by Solr 8.9.0): UserA runs a single-node 8.7.0 cluster and creates regular backups for their collections. When 8.9.0 is released they perform one final snapshot-based backup and upgrade their cluster. Shortly after upgrading their harddisk fails. They are able to restore the old snapshot-based backup by using Solr's backup API. As time goes on they can take backups with the same API call they've used previously, though the files on disk for each of these are now in the incremental-backup format.
| Info | ||
|---|---|---|
| ||
An alternative to this plan was raised on the mailing list "DISCUSS" thread, that would see the new "incremental" features only exposed via the v2 APIs, as a way to avoid backcompatibility concerns and provide a carrot to move users towards v2 at the same time. Details still forthcoming, but that might ultimately replace the deprecation plan described above. |
Test Plan
Much of this SIP can be tested as any other Solr functionality. The API changes, the framework for backups and restoration, the new restoration to existing collections functionality, and our current "BackupRepository" implementations (HDFS and local file system) can all be tested in the usual way as JUnit tests. These will likely be built off of a modified AbstractCloudBackupRestoreTestCase. Tests for the API can use LocalFileSystemRepository without any burdensome setup.
...