We have a CODESYS application running on a VM node in a Windows Hyper-V cluster. The application is thus shared on 2 different physical servers. The reason this is done is to update the servers with little to no downtime.
The setup works really well, only the sqlite database of the AlarmStorage is throwing an error. This is probably due to the fact that it is being switched from server to server and detects something unexpected happened. The AlarmStorage still works, but is showing the error "Some kind of disk I/O error occured. Check disk space". See image attached.
Bottom line: how can I resolve this disk error without having to repair the database after every server switch (data is retained)? Can it be done with pragma journal_mode off or something similar (see link with par. 7 above).
The "Application.alarmstorage.1.sqlite" has last been modified over a month ago, while new entries are being registered daily. How is this possible? Did CODESYS catch the error and changed from in-file storage to in-memory storage?
At the end of the day I don't mind how it's processed, as long as the entries are retained AND the error mentioned above is gone.
Can I safely delete the journal-file (which is used for rollbacks), and will CODESYS revert to in-file storage again then?
How can this be achieved? Should I contact support directly?
Last edit: LooijmansR 2020-11-27
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
We have a CODESYS application running on a VM node in a Windows Hyper-V cluster. The application is thus shared on 2 different physical servers. The reason this is done is to update the servers with little to no downtime.
The setup works really well, only the sqlite database of the AlarmStorage is throwing an error. This is probably due to the fact that it is being switched from server to server and detects something unexpected happened. The AlarmStorage still works, but is showing the error "Some kind of disk I/O error occured. Check disk space". See image attached.
I've read this is probably due to the journal file not writable (see https://stackoverflow.com/questions/9993555/disk-i-o-error-with-sqlite and https://sqlite.org/howtocorrupt.html, especially paragraph 7).
Bottom line: how can I resolve this disk error without having to repair the database after every server switch (data is retained)? Can it be done with pragma journal_mode off or something similar (see link with par. 7 above).
Every reply is welcomed. Thanks in advance.
Kind regards,
Reno
The "Application.alarmstorage.1.sqlite" has last been modified over a month ago, while new entries are being registered daily. How is this possible? Did CODESYS catch the error and changed from in-file storage to in-memory storage?
At the end of the day I don't mind how it's processed, as long as the entries are retained AND the error mentioned above is gone.
Can I safely delete the journal-file (which is used for rollbacks), and will CODESYS revert to in-file storage again then?
How can this be achieved? Should I contact support directly?
Last edit: LooijmansR 2020-11-27