Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sql: add ALTER RANGE RELOCATE #72305

Merged
merged 1 commit into from
Nov 23, 2021
Merged

Conversation

lunevalex
Copy link
Collaborator

This commit introduces a new ALTER RANGE RELOCATE
command, which will allow an admin to move a lease
or replica for a specific range. Unlike ALTER TABLE RELOCATE
this command works on a range_id, which makes it a lot easier
to use since the user does not have to worry about range keys, which
are difficult to deal with in an emergncy situation.

Release note (sql change): Introduce new SQL syntax ALTER RANGE RELOCATE
to move a lease or replica between stores. This is helpful in an emergency
situation to relocate data in the cluster.

@cockroach-teamcity
Copy link
Member

This change is Reviewable

pkg/sql/parser/sql.y Outdated Show resolved Hide resolved
pkg/sql/parser/sql.y Outdated Show resolved Hide resolved
pkg/sql/parser/sql.y Show resolved Hide resolved
@blathers-crl blathers-crl bot requested a review from otan November 18, 2021 21:04
@lunevalex lunevalex marked this pull request as ready for review November 18, 2021 21:05
@lunevalex lunevalex requested a review from a team as a code owner November 18, 2021 21:05
@lunevalex lunevalex requested a review from a team November 18, 2021 21:05
@lunevalex lunevalex requested a review from a team as a code owner November 18, 2021 21:05
@lunevalex
Copy link
Collaborator Author

@tbg @otan this is ready for review.

@postamar postamar removed the request for review from a team November 18, 2021 21:48
@lunevalex lunevalex force-pushed the alex/relocate branch 3 times, most recently from 68ff36a to 5ee93af Compare November 18, 2021 23:03
Copy link
Contributor

@knz knz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewed 1 of 12 files at r3.
Reviewable status: :shipit: complete! 0 of 0 LGTMs obtained (waiting on @ajwerner, @lunevalex, @nvanbenschoten, @otan, and @tbg)


pkg/sql/parser/sql.y, line 1994 at r1 (raw file):

Previously, otan (Oliver Tan) wrote…

nit: indentation

specifically, use spaces not tabs


pkg/sql/parser/sql.y, line 1981 at r3 (raw file):

alter_range_relocate_lease_stmt:
  ALTER RANGE relocate_kw LEASE TO iconst64 FOR select_stmt

Can you either extend that iconst64 to support expressions and/or placeholders, or file a followup issue to do just this.

In particular the placeholders will be important for tests.

Copy link
Collaborator Author

@lunevalex lunevalex left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewable status: :shipit: complete! 0 of 0 LGTMs obtained (waiting on @ajwerner, @knz, @nvanbenschoten, @otan, and @tbg)


pkg/sql/parser/sql.y, line 844 at r1 (raw file):

Previously, otan (Oliver Tan) wrote…

you'll probably want to add some parsing tests in pkg/sql/parser/testdata/ (make test PKG=./pkg/sql/parser TESTS=TestParse TESTFLAGS='-rewrite' to rewrite)

Done.


pkg/sql/parser/sql.y, line 1981 at r3 (raw file):

Previously, knz (kena) wrote…

Can you either extend that iconst64 to support expressions and/or placeholders, or file a followup issue to do just this.

In particular the placeholders will be important for tests.

I will add a follow up once this lands.

Copy link
Member

@tbg tbg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM from kv. I assume you'll be waiting for an LGTM on the syntax plumbing as well, since I am not a good reviewer for those.

return errors.Errorf("Expected lease to transfer to node 4")
}
// Do this to avoid snapshot problems below when we do another replica move.
if repl != tc.GetRaftLeader(t, rhsDesc.StartKey) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't be surprised if this test ended up flaky, mind giving this a bit of extra love before merge? I know CI stresses it but sometimes not enough.

panic(err)
}

b.DisableMemoReuse = true
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know what this is about, but it might be worth adding a comment.

Copy link
Collaborator Author

@lunevalex lunevalex left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewable status: :shipit: complete! 0 of 0 LGTMs obtained (waiting on @ajwerner, @knz, @lunevalex, @nvanbenschoten, @otan, and @tbg)


pkg/kv/kvserver/client_lease_test.go, line 984 at r4 (raw file):

Previously, tbg (Tobias Grieger) wrote…

Wouldn't be surprised if this test ended up flaky, mind giving this a bit of extra love before merge? I know CI stresses it but sometimes not enough.

will do


pkg/sql/opt/optbuilder/alter_range.go, line 30 at r4 (raw file):

Previously, tbg (Tobias Grieger) wrote…

I don't know what this is about, but it might be worth adding a comment.

ack

Copy link
Collaborator

@arulajmani arulajmani left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is pretty cool! 💯

Only a few nits from me, otherwise :lgtm:

Reviewed 4 of 29 files at r1, 18 of 30 files at r2, 11 of 12 files at r3, 2 of 2 files at r4, 2 of 2 files at r5, all commit messages.
Reviewable status: :shipit: complete! 1 of 0 LGTMs obtained (waiting on @ajwerner, @knz, @lunevalex, @nvanbenschoten, @otan, and @tbg)


pkg/sql/relocate_range.go, line 63 at r5 (raw file):

	}
	if !n.relocateLease {
		if n.fromStoreID <= 0 {

nit: you could collapse these two conditionals into a single one


pkg/sql/relocate_range.go, line 82 at r5 (raw file):

	return nil
}
func (n *relocateRange) Next(params runParams) (bool, error) {

nit: new line above


pkg/sql/relocate_range.go, line 130 at r5 (raw file):

func relocate(params runParams, req relocateRequest) (*roachpb.RangeDescriptor, error) {
	rangeDesc, err := lookupRangeDescriptorByRangeID(params.ctx, params.extendedEvalCtx.ExecCfg.DB, req.rangeID)

nit: wrap line at 100 chars (this and a couple more below)


pkg/sql/relocate_range.go, line 136 at r5 (raw file):

	if req.relocateLease {
		if err := params.p.ExecCfg().DB.AdminTransferLease(params.ctx, rangeDesc.StartKey, req.toStoreDesc.StoreID); err != nil {

nit: We could simply return without checking if the error is nil here.


pkg/sql/relocate_range.go, line 139 at r5 (raw file):

			return rangeDesc, err
		}
	} else {

nit: If you accept the suggestion above you could inline everything in this else block and buy a bit more indentation.


pkg/sql/relocate_range.go, line 180 at r5 (raw file):

					}
					// In small enough clusters it's possible for the same range
					// descriptor to be stored in both meta1 and meta2. This

This is probably because I'm unfamiliar with the area, but could you explain the effect of a range descriptor being stored in both meta1 and meta2 for my edification?

@lunevalex
Copy link
Collaborator Author


pkg/sql/relocate_range.go, line 180 at r5 (raw file):

Previously, arulajmani (Arul Ajmani) wrote…

This is probably because I'm unfamiliar with the area, but could you explain the effect of a range descriptor being stored in both meta1 and meta2 for my edification?

This has to do with

// 3a. the range spans meta2 and user keys, update the meta1
. We store the same range descriptor in meta1 and meta2 in cases where the range spans the meta and data keyspaces so that a meta1 lookup is always sufficient to find all meta2 entries and a meta2 lookup is always sufficient to find all data entries. As pointed out by Nathan on an internal chat thread.

@lunevalex
Copy link
Collaborator Author

TFTR!
bors r=tbg,arulajmani

@craig
Copy link
Contributor

craig bot commented Nov 23, 2021

Build failed:

Copy link
Collaborator

@arulajmani arulajmani left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

:lgtm:

Reviewable status: :shipit: complete! 1 of 0 LGTMs obtained (waiting on @ajwerner, @arulajmani, @knz, @lunevalex, @nvanbenschoten, @otan, and @tbg)


pkg/sql/relocate_range.go, line 180 at r5 (raw file):

Previously, lunevalex wrote…

This has to do with

// 3a. the range spans meta2 and user keys, update the meta1
. We store the same range descriptor in meta1 and meta2 in cases where the range spans the meta and data keyspaces so that a meta1 lookup is always sufficient to find all meta2 entries and a meta2 lookup is always sufficient to find all data entries. As pointed out by Nathan on an internal chat thread.

Looks like we're iterating over both meta1 and meta2 here, and returning the first range descriptor entry that we find. Maybe we should add a bit to this comment to say that even if two copies of the range descriptor are present, we don't care, and simply return the first one we find?

@lunevalex
Copy link
Collaborator Author

bors r+

@craig
Copy link
Contributor

craig bot commented Nov 23, 2021

Build failed:

Copy link
Collaborator Author

@lunevalex lunevalex left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewable status: :shipit: complete! 1 of 0 LGTMs obtained (waiting on @ajwerner, @arulajmani, @knz, @lunevalex, @nvanbenschoten, @otan, and @tbg)


pkg/sql/relocate_range.go, line 180 at r5 (raw file):

Previously, arulajmani (Arul Ajmani) wrote…

Looks like we're iterating over both meta1 and meta2 here, and returning the first range descriptor entry that we find. Maybe we should add a bit to this comment to say that even if two copies of the range descriptor are present, we don't care, and simply return the first one we find?

sure

Fixes cockroachdb#54971

This commit introduces a new ALTER RANGE RELOCATE
command, which will allow an admin to move a lease
or replica for a specific range. Unlike ALTER TABLE RELOCATE
this command works on a range_id, which makes it a lot easier
to use since the user does not have to worry about range keys, which
are difficult to deal with in an emergncy situation.

Release note (sql change): Introduce new SQL syntax ALTER RANGE RELOCATE
to move a lease or replica between stores. This is helpful in an emergency
situation to relocate data in the cluster.
@lunevalex
Copy link
Collaborator Author

bors r+

@craig
Copy link
Contributor

craig bot commented Nov 23, 2021

Build succeeded:

@craig craig bot merged commit a965191 into cockroachdb:master Nov 23, 2021
@lunevalex lunevalex deleted the alex/relocate branch November 29, 2021 15:06
@lunevalex
Copy link
Collaborator Author

blathers backport 21.2

@blathers-crl
Copy link

blathers-crl bot commented Dec 14, 2021

Encountered an error creating backports. Some common things that can go wrong:

  1. The backport branch might have already existed.
  2. There was a merge conflict.
  3. The backport branch contained merge commits.

You might need to create your backport manually using the backport tool.


error creating merge commit from 5487f8b to blathers/backport-release-21.2-72305: POST https://api.github.com/repos/cockroachdb/cockroach/merges: 409 Merge conflict []

you may need to manually resolve merge conflicts with the backport tool.

Backport to branch 21.2 failed. See errors above.


🦉 Hoot! I am a Blathers, a bot for CockroachDB. My owner is otan.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants