Hello self-hosters! :) I’d like to tap into your experience

tl;dr: Is it really a bad idea to use MariaDB with data over NFS?

My setup

  • RAID NFS NAS on RPi4
  • “CPU machine”, just an old laptop for now

The idea is that NAS stores the data and RAID mitigates single point of failure. Laptop is only for running the stuff, all docker-compose are under git, uploaded elswhere. Laptop fails - I buy a new refurbished one and put everything back together from data on NAS and git

Problem

But Nextcloud uses DB. ATM it sits on the laptop. And I’m thinking how to somehow move that data to the NAS.

At the beginning NAS was just for NC files, connected as NC “external storage” over SFTP. But there were issues with this setup and NFS4 turned out to not require Kerberos to work.
Since NFS docker volumes have been working quite fine, I thought about just moving the data to the NAS. But then I read this:

Generally, we recommend not to use NFS (Network File System) with MariaDB, for these reasons:

  • MariaDB data and log files on NFS volumes can become locked and unavailable for use. Locking issues may occur in cases where multiple instances of MariaDB access the same data directory, or when MariaDB is shut down improperly, for instance, due to a power outage. In particular, sharing a data directory among MariaDB instances is not recommended.

  • Data inconsistencies due to messages received out of order or lost network traffic. To avoid this issue, use TCP with hard and intr mount options.

And I feel discouraged

  • I could move whole DB (I mean including the process) to the NAS, but then operating the DB becomes NAS’ burden and breaks the responsibility separation
    I’m not a fan of this idea
  • I could treat NAS as first stage of backup for that DB data and just send the data to NAS once a day
    Also a bit meh. Getting back up from server failure will require copying the data
  • Maybe it’s not that bad to use MariaDB with NFS?
    If there is a problem with server-NAS connection, I actually don’t want Nextcloud to work at all. It should fail, so I know I need to fix something

So, what are your experiences? Is running the DB on one machine, using the data from another machine over NFS a shot in the foot?

  • shifting9810@lemmy.mrpostman.chEnglish
    4·
    8 days ago

    I have never attempted this but to me it sounds like it might lead to weird issues if nfs is slow for some reason and it will definitely make your nextcloud instance slower. You can easily just try it out though. Copy the docker compose project, start another mariadb instance with its data directory mounted from the nas. That way you can figure it out yourself.

    Personally I would just back up the database to the nas regularly. Yes if your laptop fails this requires copying data. You already need to install an os on the new laptop and pull the git repo so having one more step of copying the data should be easily doable in my opinion. Especially since you hopefully don’t plan on having your laptop break all the time.

    • INeedMana@piefed.zipOPEnglish
      1·
      8 days ago

      You can easily just try it out though

      Yeah, but if that setup leads to problem in a few months, I won’t catch that. That’s why I decided to ask and judging by the other answer, I dodged a bullet here

      Now I’m thinking of setting up something like this. Maybe even in another container? One volume with data bound, one with NFS and a bunch of scripts in entrypoint to rsync(?) between the two on inotifywait. There is lsyncd but it’s been unmaintained for two years now

      • skankhunt42@lemmy.caEnglish
        2·
        4 days ago

        I know it has been 3 days since you posted buy why not set up replication in the database it self? Sounds like you’re over complicating replication.

        I run in k8s but I have a database with local disk, and I have another cronjob that takes a backup into the first database docker init folder. Older backups end with -date so they won’t get picked up by the init script. You can do similar with just docker.

        I’ll echo everyone else. Database need local disk. I speak from experience of doing it over NFS. Even containers that have a hidden sqlite3 database should get local disk.

        • INeedMana@piefed.zipOPEnglish
          2·
          4 days ago

          replication in the database it self

          AFAIK db replication would require running another db on NAS. Which I tried to avoid

          I have another cronjob that takes a backup into the first database docker init folder. Older backups end with -date so they won’t get picked up by the init script. You can do similar with just docker.

          Yeah, that’s why I’m thinking to do. Have a container that watches changes to db data and rsyncs those into the NAS for safekeeping. My main goal in all of this is so db data won’t die with laptop’s SSD

          • skankhunt42@lemmy.caEnglish
            2·
            3 days ago

            I think the inode rsync is a bad idea. The 2nd DB would be on the NAS but its not being used by the app, so as long as it’s asynchronous writes, you should be okay.

            In either case, I hope you have backups, not just the copy

            • INeedMana@piefed.zipOPEnglish
              1·
              3 days ago

              2nd DB would be on the NAS but its not being used by the app, so as long as it’s asynchronous writes, you should be okay

              But then I have to maintain it too. And it will be using RAM that was supposed to only be for servicing RAID. On a platform where RAM can’t grow

              For sure my setup will be growing and changing with time. But ATM this “prod” db lives only on laptop’s SSD

              • skankhunt42@lemmy.caEnglish
                2·
                2 days ago

                Personally, it sounds like you’re overengineering your setup. If it’s to learn then have fun! However, if its ‘prod’ and you care about the data then you should stick to prod tested architecture. You won’t find many people (if any at all) using inode notify to rsync a database on change.

                • INeedMana@piefed.zipOPEnglish
                  1·
                  1 day ago

                  Might be! It’s just that having a container like that feels easier than looking after bare-metal secondary db

                  Maybe I’ll just pg_dump during Nextcloud maintenance window and get into BorgBackup putting the dumps on NAS? If I have to revive the db from the dead, I’ll probably just use the dump anyway, so that’s one hoop less