3 ms·

I mean SQLite is living on a single node, what exactly do you do when you have failure, when more than one process need to acces the DB, when you need RBAC etc

• warmwaffles 4y ago
  > what exactly do you do when you have failure Depends on the failure. What do you have in mind? > when more than one process need to acces the DB Easy, you use `journal_mode` set to `WAL` when you connect to the sqlite database. > when you need RBAC If you need RBAC, you aren't going to be using sqlite. In theory you could have your application handle the RBAC part since sqlite is embedded in your application. Another solution is to leverage unix users and groups and set permissions appropriately for the database file and the application running.
  • ju-st 4y ago
    >> when more than one process need to acces the DB > Easy, you use `journal_mode` set to `WAL` when you connect to the sqlite database. and set isolation level and check_same_thread and PRAGMA synchronous and then put all queries in retry loops because the DB is maybe locked https://sqlite.org/wal.html#sometimes_queries_return_sqlite_busy_in_wal_mode https://sqlite.org/wal.html#sometimes_queries_return_sqlite_... I wasted so much time trying to get multiple sqlite queries running at the same time
    • warmwaffles 4y ago
      > I wasted so much time trying to get multiple sqlite queries running at the same time You were trying to write at the same time right?
      • ju-st 4y ago
        no, although the DB was not opened readonly mode. I tested with apachebench with many parallel requests on endpoints using only SELECTs
• neverartful 4y ago
  It has everything to do with the nature of the application, architecture, business, and the business cost of such failures doesn't it? If the discussion is around failures for the use case of the article (dashboard for blogs which is read-only), my best guess at 'high availability' would be just to have a separate SQLite DB file on multiple app server nodes and call it done. The author mentions that the DB is updated once per day (probably during the night) by a cron job. Just as easy to then scp a few copies to other app server nodes. If the discussion is around a 24x7 read-write workload with high business costs for performance, availability, and scalability then it's an entirely different problem.
• simonw 4y ago
  You tell the users of your internal statistics dashboard to wait a few minutes/hours while you fix it.
• rco8786 4y ago
  > what exactly do you do when you have failure Same thing you have for failure when your pg instance is running on a single node?