The WAL and journal files must (normally) be in the same directory as the database in order that following a power-loss or system crash, the new process to open the database file will be able to find the WAL or journal and perform recovery.
If you are running in a very specialized environment, you could (if you want) create a customized VFS that writes the WAL/journal files into a separate device. Just modify the xOpen(), xAccess(), and xDelete() methods so that if the filename ends with "-journal" or "-wal" it automatically changes the pathname to point to the new volume. As long as the volumes are always mounted in the same way, and as long as all processes use your modified VFS to access the database files, this should be completely safe. On Fri, Oct 3, 2014 at 6:16 AM, Peter Waller <[email protected]> wrote: > Motivation: > > We have many thousands of sqlite databases. Our incremental block > store backups cost a lot of money. > > Judging from the disk access patterns on our machines, I strongly > suspect that sqlite is writing a lot of things which are temporary, > but amount to bytes-on-blockstore that we pay for in our backups > unnecessarily. > > Also, we have much faster local disks that are smaller, but may give a > performance benefit, since they are potentially have an order of > magnitude or two less latency than the permanent network stores. > > I understand that this might be considered highly unsuitable in many > setups, and I came across this thread here: > > > http://sqlite.1065341.n5.nabble.com/WAL-on-a-separate-filesystem-td30678.html > > But I thought I would re-ask in light of this cost and performance > motivation. Is it possible to consider a mode that enabled putting the > journal in a separate directory? > > Thanks, > > - Peter > _______________________________________________ > sqlite-users mailing list > [email protected] > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- D. Richard Hipp [email protected] _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
