38

Thought I would let you all know in case you have missed it. A few days ago Postgres support was finally merged into Sonarr dev branch (meaning 4.x version). I have already transitioned to it, so far it runs without issue

You can mostly follow the same instructions as for Radarr from here: https://wiki.servarr.com/radarr/postgres-setup

I used the following temporary docker container to do the conversion (obviously replace stuff you need to):

docker run --rm -v Route\to\sonarr.db:/sonarr.db --network=host dimitri/pgloader pgloader --debug --verbose --with "quote identifiers" --with "data only" "sqlite://sonarr.db" "postgresql://user:pwd@DB-IP/sonarr-main"

When it completed the run, it outputs a kind of table that shows if there were any errors. In my case there were 2 tables (cant remember which ones anymore) that couldn't be inserted, so I edited those manually afterwards, so it matches the ones in the original DB.

top 12 comments
sorted by: hot top controversial new old
[-] gabriele97@lemmy.g97.top 14 points 1 year ago

What are the advantages of using postgres? It makes radarr/sonarr faster?

[-] Khaelas@lemmy.world 10 points 1 year ago

I have this same question. I'm running Emby, Sonarr, Radarr and Sabnzbd on a 16GB RAM 4 year old laptop and it seems just fine performance wise. What could I be missing out on?

[-] 6xpipe_@lemmy.world 7 points 1 year ago

I was curious too, so I looked into their Github issues. Apparently, SQLite doesn't play well with k8s due to the distributed/networked nature of the environment. According to comments in the pull request, that seems to be the main driver. And apparently, Radarr already has a Postgres option.

Though, there are requests going back to 2017 to support it...just because, I guess? That person seems to just want all their data in one DB for some reason.

SQLite doesn't like NFS, the file locking isn't stable/fast enough so any latency in the storage can cause data loss, corruption or just slow things down.

However SQLite to MySQL is relatively peanuts, Postgres less so...

Still it's a nice move for those that don't run containers on a single host with local filesystems.

[-] admin@lm.boing.icu 9 points 1 year ago

Basically this. I have my home stuff running in a K3S cluster, and I had to restore my Sonarr volume several times because the SQLite DB has corrupted. Transitioning to Postgres should solve this issue, and I already have quite a few other stuff in it, for example Radarr and Prowlarr

[-] xtremeownage@lemmyonline.com 2 points 1 year ago

Longhorn storage, ceph block, or other distribed BLOCK storage can help assist this issue.

[-] admin@lm.boing.icu 1 points 1 year ago

Yeah I'm using Longhorn. Might be that I have set it up wrong, but didn't seem to have helped with the DB corruption issue.

[-] xtremeownage@lemmyonline.com 1 points 1 year ago

If you are using longhorn in RWO mode, you shouldn't have any issues as it passes block storage directly to the pod, via iscsi. No file/nfs storage involved.

[-] admin@lm.boing.icu 1 points 1 year ago

Here is what I'm using atm. Is there a better way to do this? I'm still learning K8S :)

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: sonarr-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: longhorn
  resources:
    requests:
      storage: 250Mi
***
[....]
volumes:
      - name: config
        persistentVolumeClaim:
          claimName: sonarr-pvc
[-] xtremeownage@lemmyonline.com 1 points 1 year ago

Looks correct to me.

[-] spencer@lemmy.ca 7 points 1 year ago

This is very exciting, I’ve felt that SQLite has held back the performance of the *arrs for a long time so I’m excited to see this.

[-] goncalossilva@lemm.ee 3 points 1 year ago

We'll be able to tell with real comparative data now that both options are available, but I'd be shocked if SQLite itself is the bottleneck, especially in a low concurrency scenario (which is the case for most installations of star apps).

this post was submitted on 15 Aug 2023
38 points (95.2% liked)

Selfhosted

39143 readers
415 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 1 year ago
MODERATORS