Hi everyone,
We’ve just released ServiceControl 6.22.2.
Fixed bugs
- #6094 Removed Corax search engine settings are restored on existing databases at every start-up
- #6095 Index definition change rebuilds an unlocked Lucene index on Corax when the database default is Corax
- #6096 Locked index with a changed definition starts silently with the old definition or fails with an unclear RavenDB error
All three bugs concern the RavenDB search engine for error and audit instances. ServiceControl 6.20 and later recommend migrating indexes from Corax to Lucene. These bugs can undo a migration or hide that a migrated index no longer receives updates.
From 6.22.2, ServiceControl:
- no longer writes a search engine setting to existing databases
- uses Lucene for new indexes and indexes rebuilt if the index definition also changed
- reports at startup which search engine each index uses, which indexes RavenDB rebuilds, and which locked indexes block an update.
Monitoring instances do not use RavenDB and are not affected.
How to know if you are affected
- You are affected by #6094 if you use ServiceControl 6.20.0 to 6.22.1 and removed the
Indexing.Static.SearchEngineTypeandIndexing.Auto.SearchEngineTypesettings from an error or audit database. This happens when you follow the Migrating the whole database procedure on a RavenDB server whose default is Lucene, because RavenDB Studio removes a setting that equals the server default. - You are affected by #6095 if you use ServiceControl 6.21.1 to 6.22.1 with a database whose default search engine is Corax, and an index uses Lucene without a search engine setting on the index itself. This is the case after a whole database migration when #6094 restored the Corax setting on the database.
- You are affected by #6096 if you locked an index in RavenDB Studio. The migration procedure required the lock before 6.21.1.
Symptoms
- For #6094 and #6095, indexes that were migrated to Lucene use Corax again after a restart of ServiceControl. The change back happens when an index is reset, a new index is created, or an upgrade changes an index definition. Until then, Database Settings in RavenDB Studio show both search engine settings with value
Coraxagain. - For #6095, after an upgrade that changes an index definition, the List of Indexes in RavenDB Studio shows a
ReplacementOf/<index>index that uses Corax. The instance log warnsThe following RavenDB index(es) use the Corax search engineat start-up, theError Database Search EngineorAudit Database Search Enginecustom check fails in ServicePulse, and ingestion is degraded while the index is rebuilt. - For #6096, after an upgrade that changes the definition of a locked index, an index with lock mode
Locked (ignore)keeps the old definition and the log does not mention it. An index with lock modeLocked (error)stops the instance from starting with a RavenDB exception that does not name the index.
When to upgrade
You should upgrade immediately if you are affected. Otherwise, you should upgrade during your next maintenance window.
Before starting the upgraded instance, unlock indexes in RavenDB Studio so that they can receive index-definition changes. In 6.22.2, a changed index definition locked with either Locked (ignore) or Locked (error) prevents the instance from starting. The startup error names the indexes that must be unlocked.
After the upgrade, an existing Corax index keeps Corax until its definition changes. To migrate it now, follow the migration procedure. A lock is no longer necessary.
Where to get it
You can download the new version of ServiceControl from our website or Docker Hub.
Please read our support policy for more details.
With thanks,
The team in Particular