We're a self hosted shop, we went with Valkey. Valkey also has support for RDMA, which we already is running in our infrastructure.

But that is his point. If you cannot find the session id in redis, you login again. If your Redis server crash, you start a new one and everyone just login again. No data is lost.

Sure the data is lost. A session commonly holds arbitrary state, and even if it’s just the login information. This is ridiculous.

No two processes can guarantee data consistency unless using shared memory with some kind of locking on update. And given two servers don't share memory, two processes running on these servers can not guarantee consistency either.

To put the simple terms... App writes to node-A, node-A (/process on node-A) crashes before change is synced from node-A to node-B, data is lost.

This is true for redis and true for postgresql/ mysql or any similar database. Difference between redis and a "database" is that database protects against this problem by writing change to durable storage before telling app that write is successful. Redis

So if one wants to have a consistent session storage, one should use a proper database or use AOF redis persistense with single node (https://chatgpt.com/s/t_6a24ab818e2881918db959cec8d8cc2d)

First up, if I wanted to talk to a machine, I would've asked one myself.

Then, I don't understand your point really: Yes, the CAP theorem is a thing. There are compromise solutions available however to enable highly available data storage. Some of them for Redis too, but they are more complicated than those for other database engines. Which is the point of this discussion.

Point is... with AOF and RDB enabled, and wait command used in sane manner, one can get reasonable consistency with a significant speed tradeoff and increase in application complexity. So if consistent cache is needed, one can have that with some compromises, but then probably one could use a database straight away.

Again: Redis is a database, not just a cache - it doesn’t care if you store ephemeral cache artifacts or customer records within it. Redis doesn’t pose any constraints on the type of data. Inversely, you can use Postgres as a semi or fully consistent cache.

And yes, what you’re saying is technically correct, even a well-tuned single node doesn’t solve the availability problem: if it goes down, you have an outage. To avoid that, you need multiple instances to provide the same data, avoiding downtime if one of the nodes breaks eventually.

If redis is a database, then by

> doesn’t pose any constraints on the type of data.

logic, raw disk is also a database. One just need to add block level replication to other nodes to build a replicated/ HA database.

We may not agree, but anything not providing transactions across logically related multiple data read/ update operations is not a database.

> multiple instances to provide the same data

is easy and done by a bunch of software out there, but

> multiple instances to provide the same data on non-shared memory computers, with consistency

is a really hard problem, and no one has been able to solve it yet without introducing other problems to be considered (giving up on fast performance being one of the most visible one) by architects/ developers.

Obviously these are application decisions.

You, obviously, don't commit important data only to a session that you can loose, if the application does not allow it.

We use redis as infrastructure. To route events and as a cache.

For us redis could go down and we would merely see a degradation of our service with no data loss.

I recommend using redis like that. And then use a database that supports transactions for real data problems.

But we are different. And that's OK.

This discussion is a bit weird. We started off from, Redis should have better availability guarantees. Specifically to avoid the degradation of service you described.

But that requires running on multiple instances, which in turn requires to share the data across all replicas.

If you consider it important, you have to store it in a real database. No buts. If you don't consider it important, sharded redis works fine.

Redis is a real database. If I wasn’t convinced it could retain data I hand it, I wouldn’t use it in the first place.

Just because it works for your use case right now doesn’t mean there isn’t room for improvements to support others too.

> Redis is a real database

No, redis is a memory cache, with some ACID like features bolt on.

Even real databases have hard time maintaining consistency across nodes. CAP is a real constraint.

> Redis is a real database.

Oh good, then you don't need to do any of the stuff that you suggested to do

These two concerns are not mutually exclusive, the kind of database or data stored within it doesn't give any availability guarantees on its own. Even a single Postgres instance, which I suppose fits your understanding of a real database, is a single point of failure and not a highly available setup: If your database server goes down, clients get errors and the database is thus unavailable.

When I look at the oil & gas sector, I remember MS-DOS + Wordperfect was the beginning. Then Windows 3.1 + Microsoft Office took over, and since that, its been Microsoft, Azure, and SAP.

They refuse Google Cloud, AWS, and many still believe open-source is cancer. They are Microsofts best customers. They prefer consultants over hiring software developers, and the consultants just to what they're told and never question the status quo.

Whenever I spending time at these companies, my head is filled with dinosaurs.

Where I live we have something called The ONS event/Exhibition, where the oil sector gathers to promote themself. 2 years ago AWS had a big stand there, but it was mostly empty. This year, AWS doesn't participate at all.

Yes I think we live in the same country.

Oil and gas? Dinosaurs? Can see the connection. Good luck with it next time you are with them.

I just paid 120 000 USD for replacing the exterior drainage system. I knew it was expensive, but not that expensive.

Damn, at 3k a month, that's like 3 years of rent right there.

Every time I give Photoshop a chance I give completely up, the thing doesn't even start on neither Fedora or Ubuntu and I have no interest in configuring Wine for this. GIMP is the least painful way to get the job done. I have been using it for over 20 years, and it has been a pain-free experience. That GIMP is bad is just as wrong as the people who say Java is bad.

But you know what's even worse, people that use Illustrator to create SVG's for the web. Inkscape creates proper readable SVG's at 5KB, compared to 50MB SVG's I get from Illustrator experts.

Try on Windows 11 or macOS.

https://helpx.adobe.com/photoshop/desktop/get-started/techni...

ZFS supports self healing, you do not have scrub, it will be corrected during a bad read as long you have a copy. Metadata has 2 copies by default for additional safety for a single disk.

Using a proper NIC (Chelsio) with their iSCSI accelerator will boost your iSCSI performance significantly. Another alternative is Mellanox with RDMA. You need CX4+ for optimal performance over TCP/IP, while the cheap CX3 is excellent with IPoIB. If you have a lot of packet drops and retransmissions, another option for boosting iSCSI performance is getting a network switch with a lot of memory for packet buffering. This helps with incast congestion. There are special switches with gigabytes of memory built for this.

NVMe-oF is the best protocol with least overhead for network drives, with a proper setup you lose only 10-20% latency compared to local disk even with Intel Optane. Throughput should be almost similar.

> Another alternative is Mellanox with RDMA. You need CX4+ for optimal performance over TCP/IP, while the cheap CX3 is excellent with IPoIB.

Do these benefit the iSCSI target end of the equation too, or just the initiator? And do they work like an HBA, where you configure the card in a firmware setup menu, or does it just transparently accelerate the software initiator on Windows/Linux?

It is a bit different, Mellanox with iSCSI/iSER over IB/RoCE is much less complex than iSCSI over TCP. RoCE runs over UDP, but requires switches with PFC, and ECN. Chelsio plays nice with any switch. Mellanox has much better offloading of NVMe-oF, where the network card can directly communicate with the NVMe device over pci-express so it can completely bypass system ram and host cpu. In fact, Linux will know nothing about the transfers to and from the NVMe device.

To get accelerated iSCSI, you need to install Chelsio or Mellanox drivers. While both work out of the box with the inbox drivers, they have special drivers that you have to download and install to unlock the extra performance. I think Chelsio has everything included in FreeBSD, so there the inbox drivers already come with top performance unlocked.

A 42U rack filled with 1u servers with 8 drives each, will have 84PB of data. It feels like it was a few month ago where you could buy a rack with 1PB of storage, and that was awesome. Not anymore.

I would not worry about running a distro. Most things are similar, there are some minor differences between the GNU applications and the FreeBSD alternatives. But for most people there is nothing to worry about. Most applications runs fine on BSD. Bind, PowerDNS, Java Applications, PostgreSQL, Python, rsync and many more. Getting PyTorch to work with Nvidia and Cuda is most likely another story.

My main culprit with FreeBSD is that upgrading the kernel is not a simple dnf update command. But its still easier than upgrading RHEL from 9 to 10.

I just started with FreeCAD this weekend, and in 3 hours I managed to create a simple pci bracket that I could 3dprint. I just followed some YouTube tutorials. When I learned 3D Studio Max 25 years ago, I struggled a lot more.