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

Define the placement of data by SQL statements #18030

Closed
scsldb opened this issue Jun 15, 2020 · 20 comments · Fixed by pingcap/parser#1334
Closed

Define the placement of data by SQL statements #18030

scsldb opened this issue Jun 15, 2020 · 20 comments · Fixed by pingcap/parser#1334
Labels
feature/accepted This feature request is accepted by product managers type/feature-request This is a feature requests on the product

Comments

@scsldb
Copy link

scsldb commented Jun 15, 2020

Description

TiDB supports placement rules, which can define the placement of data in a more flexible and more granular way. But it only provides configuration files to define them, and it’s complicated.

This issue tracks our progress in adding support via SQL.

The use cases for Placement Rules generally fit into two broad categories:

  1. Optimization (local stale reads) and High Availability
  2. Compliance / Geographical Restrictions

We are designing the syntax with both of these features in mind, but anticipate that initially use-case (1) will be better handled.

Sub Tasks

Named Placement Policy

(Previously: #26580 )

Support SHOW PLACEMENT

(Previously: #26582 )

Information_schema

Direct Placement Options / General Meta data

(Previously: #26581 )

table_option: {
..
 | FOLLOWERS [=] n
 | VOTERS [=] n
 | LEARNERS  [=] n
 | PRIMARY_REGION [=] "str"
 | REGIONS  [=] "str"
 | SCHEDULE [=] "str"
 | CONSTRAINTS  [=] "str"
 | FOLLOWER_CONSTRAINTS  [=] "str"
 | VOTER_CONSTRAINTS  [=] "str"
 | LEARNER_CONSTRAINTS  [=] "str"
 | PLACEMENT POLICY  [=] "str"
}

SHOW PLACEMENT LABELS

New Placement Rules Engine

(Previously: #27011 )

This is a sub-task of Placement Rules in SQL: #18030. Depends on #26580 and #26581. Once metadata has been finished, we need to add a new middle state to all related DDL jobs to sync rules to PD. Previous, we have already implemented similar code, so the work is more of a migration.

This requires the following subtasks:

Rule Removal

Others

Remove direct placement options

This is to track the changes required for #31423

Tools Behaviors

Future work

We will plan for future delivery:

@scsldb scsldb added Priority/P1 Features that will be implemented in the latest or next major/minor version type/feature-request This is a feature requests on the product labels Jun 15, 2020
@scsldb scsldb added this to the v5.0-alpha.1 milestone Jun 15, 2020
@github-actions github-actions bot added this to Need Triage in Feature Request Kanban Jun 15, 2020
@scsldb scsldb added Priority/P0 Features that will be implemented in the latest major/minor version and removed Priority/P1 Features that will be implemented in the latest or next major/minor version labels Jun 27, 2020
@scsldb scsldb modified the milestones: v5.0-alpha.1, v5.0-alpha Jun 30, 2020
@bb7133 bb7133 changed the title Improve the usability of placement rules Defines the placement of data by SQL Jul 6, 2020
@bb7133 bb7133 changed the title Defines the placement of data by SQL Define the placement of data by SQL statement Jul 6, 2020
@bb7133 bb7133 changed the title Define the placement of data by SQL statement Define the placement of data by SQL statements Jul 6, 2020
@zz-jason zz-jason moved this from Need Triage to Review Approved in Feature Request Kanban Jul 7, 2020
@zz-jason
Copy link
Member

zz-jason commented Jul 7, 2020

@djshow832 How about changing the PLACEMENT to PLACEMENT POLICY, changing label keyword to locality and changing COUNT to REPLICAS? With this, a statement that alters the geo partition policy is:

ALTER TABLE users ALTER PARTITION west
ADD PLACEMENT POLICY
    LOCALITY="+zone=west_dc"
    ROLE="leader"
    REPLICAS=1;

IMO, locality is more meaningful than label to the user, so as replicas compared with count.

@zz-jason
Copy link
Member

zz-jason commented Jul 7, 2020

CockroachDB uses CONFIGURE ZONE USING clause, they use constraints to specify label, num_replicas to specify count, for example:

ALTER PARTITION chicago OF INDEX users@*
CONFIGURE ZONE USING
    num_replicas = 3,
    constraints = '{"+region=us-central":1}',
    lease_preferences = '[[+region=us-central]]';

See https://www.cockroachlabs.com/docs/stable/topology-geo-partitioned-leaseholders.html for details.

@djshow832
Copy link
Contributor

There's a problem for locality: when adding tiflash replica through placement rules, it's often specified in the format "+engine=tiflash", it's not locality. @zz-jason

@zz-jason
Copy link
Member

There's a problem for locality: when adding tiflash replica through placement rules, it's often specified in the format "+engine=tiflash", it's not locality. @zz-jason

We use the following SQL command to add 2 tiflash replicas for table tpch50.lineitem:

ALTER TABLE `tpch50`.`lineitem` SET TIFLASH REPLICA 2

Let's regard SQL commands as the user interface, placement rules in PD as the implementation util.

In this issue, we need to design a SQL command for the user to place a partition of the table to a specific geographic position(Rack, AZ, Region, etc.). Although we are able to use this same SQL command to add TiFlash replicas, it's better not to do it this way. I prefer to use the specific SQL command to do the specific thing.

@zz-jason
Copy link
Member

I prefer to use locality, it's more specific than constraints.

@djshow832
Copy link
Contributor

So you mean, we do not support adding TiFlash replicas through the ALTER PARTITION statement? @zz-jason

kennytm pushed a commit to pingcap/parser that referenced this issue Jul 22, 2020
follow
pingcap/tidb#18030 (comment).
However, "constraints" is used for "label". Because it is not
necessarily related to region/locality.
@uglyengineer uglyengineer removed this from Backlogs in Longterm P0 Backlog Kanban Jul 25, 2020
@zz-jason zz-jason added the feature/accepted This feature request is accepted by product managers label Jul 29, 2020
Feature Request Kanban automation moved this from Finished to Need Triage Sep 16, 2021
xhebox added a commit to xhebox/tidb that referenced this issue Oct 8, 2021
follow
pingcap#18030 (comment).
However, "constraints" is used for "label". Because it is not
necessarily related to region/locality.
ti-chi-bot pushed a commit that referenced this issue Oct 9, 2021
follow
#18030 (comment).
However, "constraints" is used for "label". Because it is not
necessarily related to region/locality.
@nolouch nolouch closed this as completed Dec 20, 2022
Feature Request Kanban automation moved this from Need Triage to Finished Dec 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature/accepted This feature request is accepted by product managers type/feature-request This is a feature requests on the product
Projects
Development

Successfully merging a pull request may close this issue.

9 participants