Add startup argument to stop tablet from reparent

[systay]

No description provided.

[deepthi]

how is this different from -disable_active_reparents?
cc @enisoc

[sougou]

This looks like it's trying to protect from an external tool's error where it should not have reparented to a certain tablet.

My initial reaction is that this is an organic addition meant to handle a specific corner case. It may not necessarily play well with other operations like PlannedReparentShard, etc. We've been previously burnt by one-off flags like this, and are still stuck with many of them.

We should think of a more holistic design and approach that uniformly applies to all reparenting operations. What should that be? I don't know yet. I'll respond once I've had more time to think.

[enisoc]

@systay Can you elaborate on when you would want to run a tablet in this mode?

At face value, I agree with @sougou that this doesn't seem like a good place to put this logic. TER is meant to inform Vitess that the mysql instance under that tablet is already the master. It doesn't seem like the tablet's place to refuse to respect that command, since the contract of TER is that whatever system made that mysql instance the master should be trusted as the source of truth.

[tirsen]

This is when you run a tablet connected to an Aurora reader endpoint. That tablet should never become a MASTER. This is indeed sort of a workaround for a for a bug in an external tool.

[enisoc]

This is when you run a tablet connected to an Aurora reader endpoint. That tablet should never become a MASTER.

We could generalize this to a pattern that I've been thinking we'll need soon anyway, when we make Vitess handle automatic failover on its own. The general principle is that we need to stop assuming all REPLICA tablets are equally eligible to become masters. Up to now, REPLICA as a category has been used to denote two properties that are actually orthogonal: 1) the tablet should serve OLTP read queries, but not OLAP reads, and 2) the tablet is eligible to become a MASTER.

I do think we need to have a way to specify that some tablets serve OLTP reads, but are not master-eligible. However, I agree with @sougou that we should do this in a way that works with PlannedReparentShard and other existing commands, which perhaps means it should be stored in topology rather than only a vttablet flag.

We will also probably need a way to specify precedence among those tablets that are master-eligible (e.g. maybe you want to increase the master-preference of tablets in certain cells), but that's beyond the scope of this discussion. I only mention it to make the point that this is all the same type of stuff that Orchestrator supports, and those features have been useful, so we'll need something like that if we want to make Vitess handle everything without Orc. The other point is that we could take inspiration from how Orc expresses these kinds of preferences.

[tirsen]

I agree completely about the muddling of the two orthogonal concerns in the REPLICA tablet type. Looking forward to the refactor. In the meantime though this flag closes up a hole that has caused us production outages. Should we just merge this to our fork instead?

[enisoc]

Should we just merge this to our fork instead?

That would be my personal preference for cases like this. @sougou WDYT?

[sougou]

I can't say I like this. But fine.

[deepthi]

I thought this was going to stay in square's fork and not be merged to master?

[sougou]

ohh. I misunderstood...
Let me revert.