Document corrupted indexes or corrupted database after a service shutdown#7015
Document corrupted indexes or corrupted database after a service shutdown#7015mauroservienti merged 5 commits intomasterfrom
Conversation
|
|
||
| There is a chance that, at service shutdown, ServiceControl takes a long time to shut down and, in most cases, doesn't shut down gracefully because the RavenDB database is busy updating indexes due to ingestion and cleaning up tombstones due to retention. | ||
|
|
||
| To mitigate this situation, migrating indexes from the Corax to the Lucene indexing engine can solve the issue. It might be sufficient to migrate to Lucene the `MessagesViewIndex` (regardless of the fact that full-text search is enabled or not), which is the one with the highest load. |
There was a problem hiding this comment.
Could this backfire, and other issues occur?
We went with Corax when we upgraded to v6, so there must be a reason. It's newer and faster, maybe!
Given that you mentioned Windows, would Linux hosting be an alternative?
Or could we start promoting and supporting external RavenDB? I'm pretty sure everything works, as the containers have proven.
There was a problem hiding this comment.
Could this backfire, and other issues occur?
We have all the tests running against Lucene green. There should be no issues; Lucene has been there since day one and, despite being slower, seems more solid than Corax.
We went with Corax when we upgraded to v6, so there must be a reason. It's newer and faster, maybe!
The main reason was that RavenDB told us that sooner or later, but when it is not a thing yet, Lucene will be removed. The other thing was the performance increase promise, but it turns out that for very large databases it comes with undesirable side effects.
Given that you mentioned Windows, would Linux hosting be an alternative? Or could we start promoting and supporting external RavenDB? I'm pretty sure everything works, as the containers have proven.
That's not so easy, unfortunately. We're also testing external RavenDB without using containers, and a few assumptions in SCMU break when using an external RavenDB server. A similar issue happens on Linux containers too, but it rarely results in a corrupted database due to the different containers' lifecycles.
4 participants
No description provided.