@BrightSilence I think a simple change to your script would make it safe to use against a database that is open in another container: open the databases as a
file: URI with the
?immutable=1 query string (requires Python 3.4+). From the sqlite open docs:
immutable: The immutable parameter is a boolean query parameter that indicates that the database file is stored on read-only media. When immutable is set, SQLite assumes that the database file cannot be changed, even by a process with higher privilege, and so the database is opened read-only and all locking and change detection is disabled. Caution: Setting the immutable property on a database file that does in fact change can result in incorrect query results and/or SQLITE_CORRUPT errors. See also: SQLITE_IOCAP_IMMUTABLE.
This guarantees that sqlite will not perform any writes to the database (even journal recovery) but it does mean an error could be returned to your script if storagenode makes a concurrent write to the database. The script could capture these errors and retry the query until they succeed.
For an even higher degree of safety, the earnings script could be run from Docker with the storagenode databases provided as a read-only volume (
:ro option to
-v). This way there’s two layers of protection: sqlite in immutable mode, and if there is a sqlite bug even in this mode that tries to write to the database, aufs will reject the write to an overlay filesystem it has configured as read-only.
Obviously erroneous results could still be returned. However, this may be a happy medium between “you have to shut down your storagenode to run this script” and “you don’t shut it down but you could corrupt your database.” No shutdown and no possibility of corruption, but the very slim chance that the results are inaccurate.