51–60 of 85 posts
Earlier quoted context omitted.
This. Configure private vlans and/or Wireguard or whatever VPN software you prefer.
And what about mTLS?
I would love to see some numbers on this. My intuition says there are probably some workloads where JSON strings are better and some where one key per property is better.
I had a jr dev connect and typed 'flushall' because he thought it would refresh the dataset to disk. thankfully it was on a staging env, I think he's at google now.
Earlier quoted context omitted.
That doesn't make any sense. the timeout is how long to block for and retry, now how long to block for and continue.
Instance A grabs the lock and makes an API call that takes 120 seconds. Instance B sees the lock but considers it expired after the lock times out at 100 seconds. Instance B falsely concludes A died, overwrites A's lock so the system doesn't dead lock waiting for A, and makes its own request. Unfortunately, A's request was still processing and B's accidentally concurrent request cause corruption.
i disagree here. instance b did the right thing given the information it has. instance a should realize it no longer owns the lock and stop proceeding. but in reality it also signifies concurrency based limitations in the api itself (no ability to perform a do and then commit call). https://microservices.io/patterns/data/saga.html
Earlier quoted context omitted.
Isn’t it another ticking time bomb to accept writes that will be lost if the server is shut down?
Expecting that any key in redis will be there next time you read it is a ticking timebomb. Redis is not a database. It's a cache. Unless you're using AOF mode with fsync always, you can lose writes. If you're doing that, you should be using a real database instead.
> The open source, in-memory data store
Earlier quoted context omitted.
My understanding is elasticache does not let you turn them off.
That would be surprising, have you tried with CONFIG SET xyz ?
I had a jr dev connect and typed 'flushall' because he thought it would refresh the dataset to disk. thankfully it was on a staging env, I think he's at google now.
If a junior dev can cause catastrophic harm from one wrong command, it's the org's fault for not having safeguards in place, not the dev's fault for an (understandable) error.
Has anyone seen max (p100) client latencies of 300 to 400ms but totally normal p99? We see this across almost all our redis clusters on elasticache and have no idea why. CPU usage is tiny. Slowlog shows nothing.
Earlier quoted context omitted.
Expecting that any key in redis will be there next time you read it is a ticking timebomb. Redis is not a database. It's a cache. Unless you're using AOF mode with fsync always, you can lose writes. If you're doing that, you should be using a real database instead.
The first line of redis.io: > The open source, in-memory data store
Earlier quoted context omitted.
That doesn’t make sense, they can’t assume the lock is freed after the timeout. They have to retry to get the lock again, because another process might have taken the lock. Also, redis is single threaded so access to redis is by definition serialized.
The lock is explicitly release by the redis server itself after the ttl. It's not that the Client will assume that the lock is released.