New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
I agree with @emgh here as I find it strange to say at least
Why?
JSON is a native data type in Postgres (and other RDBMSes). It's as normal (no database pun in tended) to put it in Pg as it is in MongoDB. They're "tables" instead of "collections" but...
Why would I need a specialized database for, say, internet addresses, for example - these are also native data types in Pg. Or for dates/times. Or etcetera. So why a specialized DB for JSON?
I've worked with MongoDB and it's easy to use, though it has a frightful record of data safety and is not free. But really, anything you can do in NoSQL you can do in an RDBMS.
lol, I have always said rational and have been corrected so many times it's embarrassing
is it though? In MongoDB, JSON is a first class citizen, it's the data. In PostgreSQL, it's a data TYPE. MongoDB is built around JSON, PostgreSQL is built to work with JSON.
i use mount option "compress=zstd:15" ,this should get max compression ratio
At home, I use compress=zstd:3 (so it's not too slow). But with the old 4.x kernel in the VPS rescue environment, zstd isn't even available.
But I don't think that JSON fits even first normal form.
Azure Cosmos DB from Microsoft is a NoSQL database. One variant uses a Postgres backend (also available as the open-source DocumentDB).
I think it’s worth checking why they went with Postgres instead of Mongo.
MongoDB does not use or enforce normal forms at all, and PostgreSQL introduces a multi-model approach.
If you’re not already convinced, none of those reasons would convince you. It’s just fluff.
I found my notes from last year, here's how the corruption looked like when running MariaDB on top of a BTRFS volume:
Even though in this instance the errors are related to Galera (wsrep), the same kind of corruption happened on MariaDB instances running on physical hosts without Galera, the only common factor was the BTRFS filesystem.
The quick fix was, as pointed out in this thread, to set the
nodatacowattribute on the MariaDBdatadir: after 10 days of operation, no corruption happened on the databases where the issue appeared daily.I moved to XFS anyways, as it seemed better suited to this use case.
Do you remember how long it had been running on BTRFS before you started getting those errors?
Not really, I know for sure that the issue came up when I was running Fedora 39 on all hosts, but I haven't kept notes of the exact versions or updates to the kernel or MariaDB. I just thought that I was running such a niche setup that the most effective way to get rid of the issue was to switch to a different filesystem.
why don't you upgrade linux kernel
It's the kernel in the "Rescue Mode" recovery environment supplied by the provider in SolusVM.
The only selections are:
It's not something I can upgrade. This is the kernel that needs to format, mount, and restore.
I've noticed it's the same selection in SolusVM with different providers, too. So I suspect it's just built into SolusVM like that.
I don't understand, linux kernel should be part of distribution, it should auto up to date when you upgrade your linux system.Like if i use alpine,the lastest stable kernel should be 6.12.31-0
It's not the kernel used by the distribution that is normally running, it's the kernel in the "Rescue Mode" which is a different distribution and kernel that is set by the provider and SolusVM. It's in this Rescue Mode that the formatting, mounting, and restore takes place.
oh i see.
Can you boot a dvd iso file from pannel, check this https://www.finnix.org/. Use this as rescue mode
Yes, you could do something like that. But some of my providers require a support ticket to mount an iso, so it's a hassle.