Not sure I'm doing this right ...

[vc1cv1]

Hi All,

I was under the impression that marmot can be used on a production (in-use/live) database. Am I mistaken about that?
I have a db.sqlite3 in-use within a docker container and when I run marmot with the db_path to the live production path, it doesn't work. But, if I copy the db.sqlite3 lite to /tmp and update the toml config file, it works fine.

I can get the test config using /tmp path with a 2nd node working properly as well. It's only during this testing of pointing to the live production db path that I am seeing the forcing wal checkpoint...

--------- ERROR
marmot -config ./vw1-test.toml 
4:05PM DBG Opening database node_id=1 path=/home/vw-data/db.sqlite3
4:05PM DBG Forcing WAL checkpoint node_id=1

vw1-test.toml config

`eq_map_path="/tmp/marmot-db-sqlite3-vw1-sm.cbor"
#db_path="/tmp/db.sqlite3"
db_path="/home/vw-data/db.sqlite3"
node_id=1

[nats]
bind_address="0.0.0.0:4222"
subject_prefix="marmot-change-log"
stream_prefix="marmot-changes"

[logging]
verbose=true
format="console"
`

[maxpert]

Hey so yes Marmot is being used in production. At boot time Marmot tries to flush everything to disk, so that DB is snapshot ready and there are no outstanding WAL changes. If you have a process that is locking down DB and won't release lock under (10s or 30s I have to check), in that case this will fail. Since Marmot is a process based replication it's very important that you don't hold lock on DB forever because then Marmot can't step in and replicate changes.

[vc1cv1]

Thanks for input about the lock and WAL ... I've never dealt with sql/sqlite3 in this manner before and understand all the nuances of it. Turns out, it was litestream locking it and not my application in Docker ... :-) Thank you for Marmot, just what I need to test replication of my database! Now to figure out the cluster stuff.

[maxpert]

Follow the examples, I've put together. It should be very simple. Again feel free to drop on discord DM if you don't wanna discuss details publicly here.