What is it with Postgres fans that "have to" prove they're better? I don't want to use Postgres. I want to use Redis. Postgres IS NOT the solution for a lot of things. Yeah, feel free to call me stupid for not knowing every nook and cranny of PGSQL. I don't care "I love to argue, but this is just a futile exercise." Very wise words
Why I can't have conversations using Twitter
121–130 of 161 posts
Re: Why I can't have conversations using Twitter
#122Maybe if antirez doesn't want to read others simplistic responses on Twitter, he shouldn't make simplistic statements on Twitter. It's clearly a medium that doesn't convey nuance very well. There was a great deal of misinterpretation and talking past one another on all sides including his. This was actually a continuation of a conversation that has been going on for several days, starting with an issue even more seri…
Did you read the post? "the 99% percentile is bad" is something I never wrote, it was part of a larger sentence where it was obvious it meant if the 99th percentile figure is too big. About pointing to relevant papers: things like pointing to timestamped replication paper, which is a CP system for replicated state machines, in response to the fact that Redis does not support slaves when the master disk persistence is…
As for your false dichotomy between reading the literature and getting stuff done, or your "make the effort to understand" ad hominem - go to hell. I've been doing this longer than you, I've been doing it better than you, and I've been writing about it as well. You make the effort to understand the problem before you shoot yourself in the foot yet again.
Re: Why I can't have conversations using Twitter
#123Earlier quoted context omitted.
I would agree that iteration through thought is not necessarily a useful constraint on a medium by itself. In the case of twitter, however, it is merely a product of the 140-character limit for each message. If, during a stand-up debate, your opponent was allowed to interject after every sentence, you would get much the same. That sounds incredibly annoying and counter-productive at first, but the form of the debate…
Hrm, what you are suggesting sounds like some kind of conversation back and forth between 2 people. Like a chat system or something. Issue is, you are talking in an environment where everyone can interject, and everyone has a strongly felt opinion. Just look at any news show "interview" between 2 sides of an argument. They tend to devolve into shouting matches of who can drown out the other side without getting smack…
It's true that it's easy for people to interject and annoy, and it happens more and more the bigger your celebrity status. However, unlike the interview example, it's also easy to ignore them. Twitter's reply helped a lot for that. Replying to anybody is optional, you don't even have to read their tweets if you don't want to. It's not perfect by any means, I don't think any platform will ever be. But it isn't bad.
Re: Why I can't have conversations using Twitter
#124Earlier quoted context omitted.
Did you read the post? "the 99% percentile is bad" is something I never wrote, it was part of a larger sentence where it was obvious it meant if the 99th percentile figure is too big. About pointing to relevant papers: things like pointing to timestamped replication paper, which is a CP system for replicated state machines, in response to the fact that Redis does not support slaves when the master disk persistence is…
See my response to seiji. Exact mimicry might be a defined behavior, but where is it mandated who should mimic whom? Where had you said, before this, that the node with no data must be the one whose (empty) view should prevail? As for your false dichotomy between reading the literature and getting stuff done, or your "make the effort to understand" ad hominem - go to hell. I've been doing this longer than you, I've b…
In Redis if you don't use any HA system like Sentinel, the map is fixed, it is an old-style replication system where there is the master IP address written in the configuration file.
Since the system is not supposed to lose the data on restarts, this is fine, but as soon as you want to support a different mode of operation with persistence-less masters, this must be modified, being Redis used with HA or not.
Now if you want to put Sentinel in the mix, the problem with this setup is not that the returning master gets promoted with a broken data set, but that if the restart is fast enough, the failure detection of Sentinel is not triggered at all, so the configuration remains the same. Just what is still, and was previous of the reboot, the current master of the system, restarted with a wiped data set.
In distributed systems this is the process not acting as specified, since Redis processes must reload their dataset on restart, otherwise they break everything, per design.
Now if it is a good idea to change this design: in the future yes, but so far we had not diskless replication, so for the replica to synchronize to write on disk was, anyway, needed, so why turn off persistence, and why to support it if the disk is needed anyway?
See? Arguments instead of random blabling and we can construct a reality or a model we both agree about. Then we can debate about what we think is right or not.
Re: Why I can't have conversations using Twitter
#125Earlier quoted context omitted.
Did you read the post? "the 99% percentile is bad" is something I never wrote, it was part of a larger sentence where it was obvious it meant if the 99th percentile figure is too big. About pointing to relevant papers: things like pointing to timestamped replication paper, which is a CP system for replicated state machines, in response to the fact that Redis does not support slaves when the master disk persistence is…
See my response to seiji. Exact mimicry might be a defined behavior, but where is it mandated who should mimic whom? Where had you said, before this, that the node with no data must be the one whose (empty) view should prevail? As for your false dichotomy between reading the literature and getting stuff done, or your "make the effort to understand" ad hominem - go to hell. I've been doing this longer than you, I've b…
Re: Why I can't have conversations using Twitter
#126Re: Why I can't have conversations using Twitter
#127I don't think this is due to the limit of 140 characters (even if it doesn't help) but much more due to the audience of fanboys and crow cheered during a fight. There is the same problem on Google+ where there is not 140 characters limit. Any discussions with Linus or any other "celebrity" in it and the comments thread will be full of : "+1", "M. Linus you are so smart, you are my hero", "Well said, ripe him a new on…
I agree that this is not a problem that only affects Twitter. Most of the current discussion platforms are way behind what was standard in Usenet or in your average Usenet client. No threaded discussions, no filtering (not for the one who comments and doesn't want to read those +1 post and most often also not for the OP), not even blocking of people you don't want to read.
Re: Why I can't have conversations using Twitter
#128Earlier quoted context omitted.
data loss due to a broken replica-repair strategy. That's the thing: Redis has no read repair strategy. Redis has a "be an exact copy of your master" strategy. It's not a secret. It's the exact design. The complaints are like yelling at Linus when you rm -rf / your entire machine. Sure, it sucks, but it's a repercussion if your own actions, not a fault in the system. If you don't want to rm -rf / your machine, go use…
When you say "be an exact copy of your master" is the strategy, you're kind of missing the problem here - who should be the master? In this case, Redis made a really dumb choice of which node should be master, and brought everything in sync by replicating emptiness instead of replicating data. There are very few use cases where that would be preferable. People have pointed out well known and fairly simple solutions t…
The choice of master is a static configuration set by the user.
Redis itself has no failover or promotion ability. There's an additional thing called Sentinel that can failover and promote individual Redis instances, but it is designed to recover complete instance failures (without immediately restarting), so a quick restart means no failover happens [an improvement to the "quick restart" scenario is showing up soon].
Redis made a really dumb choice of which node should be master,
(see previously; master is static, defined by the user)
pointed out well known and fairly simple solutions to the selection problem
(redis doesn't select things)
Also, this issue showed up last week. Last week. People are making it sound like this issue has been ignored for years. Nobody ran into this (and reported it) until recently. This use case is already being adapted into SOP Redis capabilities soon.
Try running into a big problem with any other DB and getting both attention and a concrete fix within two weeks. For free. The entire progress of the project has paused to address these immediate user issues.
because that's well defined, well documented, and well known behavior.
The Redis behavior is: always be a copy of a statically configured master. When the master has an empty dataset, all the replicas replicate an empty dataset. Pretty simple. :)
No spec or doc precluded choosing a different master and preserving data instead of discarding it.
Yup, specs and documentation did exactly that. Redis has no failover capability on its own.
preserving data should always be the default.
Ooops, you just re-invented the Mac trashcan.
How can it be user error when the user did nothing?
The user disabled persistence, enabled replication, restarted the process with zero data, then the replication recovered and stayed in sync with the newly zero-data master.
something was missed in its implementation, not because of any rational or deliberate choice.
nopers. more a lack of thinking it through from the user's point of view. an exact copy of nothing ends up being nothing.
Re: Why I can't have conversations using Twitter
#129Earlier quoted context omitted.
See my response to seiji. Exact mimicry might be a defined behavior, but where is it mandated who should mimic whom? Where had you said, before this, that the node with no data must be the one whose (empty) view should prevail? As for your false dichotomy between reading the literature and getting stuff done, or your "make the effort to understand" ad hominem - go to hell. I've been doing this longer than you, I've b…
"but where is it mandated who should mimic whom" In Redis if you don't use any HA system like Sentinel, the map is fixed, it is an old-style replication system where there is the master IP address written in the configuration file. Since the system is not supposed to lose the data on restarts, this is fine, but as soon as you want to support a different mode of operation with persistence-less masters, this must be mo…
"Old style" doesn't explain it. Even if the original master has unconditional priority when it returns, that does not preclude it gathering whatever data might still exist from the others. I've been working on replication systems since '92, and I can't recall seeing any that would make such a poor choice. Can you point to any, or is this really a "new style" idea?
"we can construct a reality or a model we both agree about."
I will concede that the behavior might be compliant with how the system was specified. I'm not 100% convinced yet, but at least - now - you've made a credible case for that.
"Then we can debate about what we think is right or not."
Not. The data-preserving mechanisms (e.g. view/epoch IDs) are so easy to implement in this case that leaving them out is unjustifiable. You even seem to be coming around to that view yourself when you say "in the future yes" but apparently you can't bring yourself to admit that it was always the right choice.
Re: Why I can't have conversations using Twitter
#130Earlier quoted context omitted.
When you say "be an exact copy of your master" is the strategy, you're kind of missing the problem here - who should be the master? In this case, Redis made a really dumb choice of which node should be master, and brought everything in sync by replicating emptiness instead of replicating data. There are very few use cases where that would be preferable. People have pointed out well known and fairly simple solutions t…
you're kind of missing the problem here - who should be the master? The choice of master is a static configuration set by the user. Redis itself has no failover or promotion ability. There's an additional thing called Sentinel that can failover and promote individual Redis instances, but it is designed to recover complete instance failures (without immediately restarting), so a quick restart means no failover happens…
Hasn't it been? How does leaving that latent in the system for years make things better? I rather think it reflects on an inability to reason about failure modes (including user failure modes), and deal with them proactively instead of after data was lost.