044、TiDB特性_PlacementPolicy

已于 2023-12-25 21:43:45 修改
阅读量433 收藏
点赞数
分类专栏： TiDB从入门到精通 文章标签： tidb 数据库
于 2023-07-16 20:15:05 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/wangzhicheng987/article/details/130788364
版权

Placement Rules in SQL之前

  • 跨地域部署的集群，无法本地访问
  • 无法根据业务隔离资源
  • 难以按照业务登记配置资源和副本数

在这里插入图片描述

Placement Rules in SQL之后

  • 跨地域部署的集群，支持本地访问
  • 根据业务隔离资源
  • 按照业务等级配置资源和副本数
    在这里插入图片描述

配置 labels

设置 TiKV 的 labels 配置

Region放置规则

  • 用户可以将表指定部署到不同的地域、主机
  • 支持应用跨地域部署
  • 保证本地的数据副本可用于本地stale read读取
mysql> show placement labels;
+--------+----------------+
| Key    | Values         |
+--------+----------------+
| disk   | ["hdd", "ssd"] |
| region | ["bj", "sz"]   |
+--------+----------------+
2 rows in set (0.00 sec)
注意： 这个region的概念不是TiKV最小存储管理单元，而是自定义作为地域标签的意思。

在这里插入图片描述
在这里插入图片描述

TiKV 支持在命令行参数或者配置文件中以键值对的形式绑定一些属性，我们把这些属性叫做标签（label）。TiKV 在启动后，会将自身的标签上报给 PD，因此我们可以使用标签来标识 TiKV 节点的地理位置。例如集群的拓扑结构分成三层：机房（zone) -> 机架（rack）-> 主机（host），就可以使用这 3 个标签来设置 TiKV 的位置。

使用命令行参数的方式：

tikv-server --labels zone=<zone>,rack=<rack>,host=<host>

使用配置文件的方式：

[server]
labels = "zone=<zone>,rack=<rack>,host=<host>"

设置 PD 的 location-labels 配置

根据前面的描述，标签可以是用来描述 TiKV 属性的任意键值对，但 PD 无从得知哪些标签是用来标识地理位置的，而且也无从得知这些标签的层次关系。因此，PD 也需要一些配置来使得 PD 理解 TiKV 节点拓扑。

PD 上的配置叫做 location-labels，在集群初始化之前，可以通过 PD 的配置文件进行配置。

[replication]
location-labels = ["zone", "rack", "host"]

如果需要在 PD 集群初始化完成后进行配置，则需要使用 pd-ctl 工具进行在线更改：

pd-ctl config set location-labels zone,rack,host

其中，location-labels 配置是一个字符串数组，每一项与 TiKV 的 labels 的 key 是对应的，且其中每个 key 的顺序代表了不同标签的层次关系。

注意
必须同时配置 PD 的 location-labels 和 TiKV 的 labels 参数，否则 PD 不会根据拓扑结构进行调度。

使用 TiUP 进行配置（推荐）
如果使用 TiUP 部署集群，可以在初始化配置文件中统一进行 location 相关配置。TiUP 会负责在部署时生成对应的 TiKV 和 PD 配置文件。

下面的例子定义了 zone/host 两层拓扑结构。集群的 TiKV 分布在三个 zone，每个 zone 内有两台主机，其中 z1 每台主机部署两个 TiKV 实例，z2 和 z3 每台主机部署 1 个实例。以下例子中 tikv-n 代表第 n 个 TiKV 节点的 IP 地址。

server_configs:
  pd:
    replication.location-labels: ["zone", "host"]

tikv_servers:
# z1
  - host: tikv-1
    config:
      server.labels:
        zone: z1
        host: h1
   - host: tikv-2
    config:
      server.labels:
        zone: z1
        host: h1
  - host: tikv-3
    config:
      server.labels:
        zone: z1
        host: h2
  - host: tikv-4
    config:
      server.labels:
        zone: z1
        host: h2
# z2
  - host: tikv-5
    config:
      server.labels:
        zone: z2
        host: h1
   - host: tikv-6
    config:
      server.labels:
        zone: z2
        host: h2

基于拓扑 label 的 PD 调度策略
PD 在副本调度时，会按照 label 层级，保证同一份数据的不同副本尽可能分散。

下面以上一节的拓扑结构为例分析。

假设集群副本数设置为 3（max-replicas=3），因为总共有 3 个 zone，PD 会保证每个 Region 的 3 个副本分别放置在 z1/z2/z3，这样当任何一个数据中心发生故障时，TiDB 集群依然是可用的。

假如集群副本数设置为 5（max-replicas=5），因为总共只有 3 个 zone，在这一层级 PD 无法保证各个副本的隔离，此时 PD 调度器会退而求其次，保证在 host 这一层的隔离。也就是说，会出现一个 Region 的多个副本分布在同一个 zone 的情况

示例一： 初始化集群时配置

1、编辑配置文件

[root@tidb2 ~]# more scale_out_all.yaml 
# # Global variables are applied to all deployments and used as the default value of
# # the deployments if a specific deployment value is missing.
global:
 user: "root"
 ssh_port: 22
 deploy_dir: "/tidb-deploy"
 data_dir: "/tidb-data"
server_configs:
 pd:
  replication.location-labels: ["zone","dc","rack","host"]  # pd需要跟tikv当中的配置对应上

pd_servers:
 - host: 192.168.16.13

tidb_servers:
 - host: 192.168.16.13

tikv_servers:
 - host: 192.168.16.13 
   ssh_port: 22
   port: 20160
   status_port: 20180
   deploy_dir: "/tidb-deploy/tikv-20160"
   data_dir: "/tidb-data/tikv-20160"
   config:
     server.labels:
       zone: bj			# zone dc rack host 这些只是标签，可自定义
       dc: bja
       rack: rack1
       host: host1
 - host: 192.168.16.13 
   ssh_port: 22
   port: 20161
   status_port: 20181
   deploy_dir: "/tidb-deploy/tikv-20161"
   data_dir: "/tidb-data/tikv-20161"
   config:
     server.labels:
       zone: sz	# zone dc rack host 这些只是标签，可自定义
       dc: sza
       rack: rack1
       host: host1

2、部署集群

tiup cluster deploy tidb-test v6.1.0 ./scale_out_all.yaml --skip-create-user

3、查看信息

mysql> select store_id,address,store_state_name,label from information_schema.tikv_store_status;
+----------+---------------------+------------------+---------------------------------------------------------------------------------------------------------------------------------------+
| store_id | address             | store_state_name | label                                                                                                                                 |
+----------+---------------------+------------------+---------------------------------------------------------------------------------------------------------------------------------------+
|        1 | 192.168.16.13:20161 | Up               | [{"key": "zone", "value": "sz"}, {"key": "rack", "value": "rack1"}, {"key": "host", "value": "host1"}, {"key": "dc", "value": "sza"}] |
|        4 | 192.168.16.13:20160 | Up               | [{"key": "zone", "value": "bj"}, {"key": "rack", "value": "rack1"}, {"key": "host", "value": "host1"}, {"key": "dc", "value": "bja"}] |
+----------+---------------------+------------------+---------------------------------------------------------------------------------------------------------------------------------------+
2 rows in set (0.01 sec)



mysql> show placement labels;
+------+----------------+
| Key  | Values         |
+------+----------------+
| dc   | ["bja", "sza"] |
| host | ["host1"]      |
| rack | ["rack1"]      |
| zone | ["bj", "sz"]   |
+------+----------------+
4 rows in set (0.00 sec)

示例一： 初始化后设置label

[root@tidb2 ~]# more scale_out_all2.yaml 
# # Global variables are applied to all deployments and used as the default value of
# # the deployments if a specific deployment value is missing.
global:
 user: "root"
 ssh_port: 22
 deploy_dir: "/tidb-deploy"
 data_dir: "/tidb-data"

pd_servers:
 - host: 192.168.16.13

tidb_servers:
 - host: 192.168.16.13

tikv_servers:
 - host: 192.168.16.13

1、pd添加locaton-labels信息

 ./pd-ctl -u http://192.168.16.13:2379 config set location-labels region,disk
 Success!

2、创建具有不同label的tikv

[root@tidb2 ~]# more scale-out-tikv.yaml
tikv_servers:
 - host: 192.168.16.13 
   ssh_port: 22
   port: 20162
   status_port: 20182
   deploy_dir: "/tidb-deploy/tikv-20162"
   data_dir: "/tidb-data/tikv-20162"
   config:
     server.labels:
       region: bj
       disk: hdd
 - host: 192.168.16.13 
   ssh_port: 22
   port: 20161
   status_port: 20181
   deploy_dir: "/tidb-deploy/tikv-20161"
   data_dir: "/tidb-data/tikv-20161"
   config:
     server.labels:
       region: sz
       disk: ssd

[root@tidb2 ~]# tiup cluster scale-out tidb-test scale-out-tikv.yaml
  • 添加具有lable的tikv server
    集群中有⼀台被打上标签的tikv 创建集群的手，暂时只添加一个kv，并且打上标签
tiup playground v6.1.0 --tag classroom-geo --db 2 --pd 3 --kv 1 --tiflash 1 --kv.config ./label-geo-shanghai-ssd.toml --host 192.168.16.12

tiup playground scale-out --kv 1 --kv.config ./label-geo-seattle-hdd.toml
tiup playground scale-out --kv 1 --kv.config ./label-geo-seattle-ssd.toml
tiup playground scale-out --kv 1 --kv.config ./label-geo-shanghai-hdd.toml
tiup playground scale-out --kv 1 --kv.config ./label-geo-shanghai-ssd.toml

注意： 这个region 不是说tikv的存储单元，这个就是地区的意思，用于打标签，自定义的。

查看系统有哪些标签

mysql> show placement labels;
+--------+----------------+
| Key    | Values         |
+--------+----------------+
| disk   | ["hdd", "ssd"] |
| region | ["bj", "sz"]   |
+--------+----------------+
2 rows in set (0.04 sec)

mysql> select store_id,address,store_state_name,label from information_schema.tikv_store_status;
+----------+---------------------+------------------+---------------------------------------------------------------------+
| store_id | address             | store_state_name | label                                                               |
+----------+---------------------+------------------+---------------------------------------------------------------------+
|        1 | 192.168.16.13:20160 | Up               | null                                                                |
|       69 | 192.168.16.13:20161 | Up               | [{"key": "region", "value": "sz"}, {"key": "disk", "value": "ssd"}] |
|       68 | 192.168.16.13:20162 | Up               | [{"key": "region", "value": "bj"}, {"key": "disk", "value": "hdd"}] |
+----------+---------------------+------------------+---------------------------------------------------------------------+
3 rows in set (0.01 sec)

类似给Region打标签，例如我是西雅图的，优先访问Seattle, 上海的优先访问shanghai.但也有一个问题 Leader（shanghai）和flower（Seattle）同步的问题，那可能对实时性没这么强的表可以这样处理。

placement policy

创建placement policy

前提： 启动节点的时候，配置了lable。

创建放置规则

CREATE PLACEMENT POLICY IF NOT EXISTS east PRIMARY_REGION="sz" REGIONS="sz,bj" FOLLOWERS=2;
# PRIMARY_REGION : leader 角色
#FOLLOWERS :副本数量
#REGIONS : follower 角色region位置
mysql> CREATE PLACEMENT POLICY IF NOT EXISTS west PRIMARY_REGION="bj" REGIONS="bj,sz" FOLLOWERS=2;
Query OK, 0 rows affected (0.20 sec)

这个里面的region有是指打了sz bj标签的 TiDB当中的存储单元。

  • placement_policies表
mysql> select * from information_schema.placement_policies \G;
*************************** 1. row ***************************
           POLICY_ID: 1
        CATALOG_NAME: def
         POLICY_NAME: east
      PRIMARY_REGION: sz
             REGIONS: sz,bj
         CONSTRAINTS: 
  LEADER_CONSTRAINTS: 
FOLLOWER_CONSTRAINTS: 
 LEARNER_CONSTRAINTS: 
            SCHEDULE: 
           FOLLOWERS: 2
            LEARNERS: 0
*************************** 2. row ***************************
           POLICY_ID: 2
        CATALOG_NAME: def
         POLICY_NAME: west
      PRIMARY_REGION: bj
             REGIONS: bj,sz
         CONSTRAINTS: 
  LEADER_CONSTRAINTS: 
FOLLOWER_CONSTRAINTS: 
 LEARNER_CONSTRAINTS: 
            SCHEDULE: 
           FOLLOWERS: 2
            LEARNERS: 0
2 rows in set (0.03 sec)

ERROR: 
No query specified

创建表

设定数据对象的placement policy

#  建表的时候指定存放规则
DROP TABLE IF EXISTS test.t_east;
CREATE TABLE test.t_east(
 id bigint primary key auto_random,
 name varchar(30),
 t_mark timestamp default now()
) PLACEMENT POLICY = east;
DROP TABLE IF EXISTS test.t_west;
CREATE TABLE test.t_west(
 id bigint primary key auto_random,
 name varchar(30),
 t_mark timestamp default now()
) PLACEMENT POLICY = west;

插⼊数据

insert into test.t_east (name) values (0),(1),(2),(3),(4),(5),(6),(7),(8),(9);
insert into test.t_west (name) values (0),(1),(2),(3),(4),(5),(6),(7),(8),(9);
SELECT SLEEP(1);
insert into test.t_east (name) select name from test.t_east;
insert into test.t_west (name) select name from test.t_west;
SELECT SLEEP(1);
insert into test.t_east (name) select name from test.t_east;
insert into test.t_west (name) select name from test.t_west;
SELECT SLEEP(1);
insert into test.t_east (name) select name from test.t_east;
insert into test.t_west (name) select name from test.t_west;
SELECT SLEEP(1);
insert into test.t_east (name) select name from test.t_east;
insert into test.t_west (name) select name from test.t_west;
SELECT SLEEP(1);
insert into test.t_east (name) select name from test.t_east;
insert into test.t_west (name) select name from test.t_west;
SELECT SLEEP(1);
insert into test.t_east (name) select name from test.t_east;
insert into test.t_west (name) select name from test.t_west;
SELECT SLEEP(1);
insert into test.t_east (name) select name from test.t_east;
insert into test.t_west (name) select name from test.t_west;
SELECT SLEEP(1);
insert into test.t_east (name) select name from test.t_east;
insert into test.t_west (name) select name from test.t_west;
SELECT SLEEP(1);
insert into test.t_east (name) select name from test.t_east;
insert into test.t_west (name) select name from test.t_west;
SELECT SLEEP(1);
insert into test.t_east (name) select name from test.t_east;
insert into test.t_west (name) select name from test.t_west;
SELECT SLEEP(1);
insert into test.t_east (name) select name from test.t_east;
insert into test.t_west (name) select name from test.t_west;
SELECT SLEEP(1);
insert into test.t_east (name) select name from test.t_east;
insert into test.t_west (name) select name from test.t_west;
SELECT SLEEP(1);
insert into test.t_east (name) select name from test.t_east;
insert into test.t_west (name) select name from test.t_west;
analyze table test.t_east;
analyze table test.t_west;

查看放置规则

/* Show status */
select kvrs.region_id, kvss.store_id, kvrp.is_leader, kvss.label,
kvss.start_ts
 from information_schema.tikv_region_status kvrs
 join information_schema.tikv_region_peers kvrp
 on kvrs.region_id = kvrp.region_id
 join information_schema.tikv_store_status kvss
 on kvrp.store_id = kvss.store_id
 join information_schema.tables t
 on t.table_name = kvrs.table_name
 where t.table_schema='test'
 and t.table_name='t_east';
+-----------+----------+-----------+---------------------------------------------------------------------+---------------------+
| region_id | store_id | is_leader | label                                                               | start_ts            |
+-----------+----------+-----------+---------------------------------------------------------------------+---------------------+
|     38013 |       69 |         1 | [{"key": "region", "value": "sz"}, {"key": "disk", "value": "ssd"}] | 2023-07-05 05:58:23 |
|     38013 |       68 |         0 | [{"key": "region", "value": "bj"}, {"key": "disk", "value": "hdd"}] | 2023-07-05 05:58:22 |
|     38013 |        1 |         0 | null                                                                | 2023-07-05 05:58:22 |
+-----------+----------+-----------+---------------------------------------------------------------------+---------------------+
3 rows in set (0.05 sec)


select kvrs.region_id, kvss.store_id, kvrp.is_leader, kvss.label,
kvss.start_ts
 from information_schema.tikv_region_status kvrs
 join information_schema.tikv_region_peers kvrp
 on kvrs.region_id = kvrp.region_id
 join information_schema.tikv_store_status kvss
 on kvrp.store_id = kvss.store_id
 join information_schema.tables t
 on t.table_name = kvrs.table_name
 where t.table_schema='test'
 and t.table_name='t_west';

+-----------+----------+-----------+---------------------------------------------------------------------+---------------------+
| region_id | store_id | is_leader | label                                                               | start_ts            |
+-----------+----------+-----------+---------------------------------------------------------------------+---------------------+
|     38021 |       69 |         0 | [{"key": "region", "value": "sz"}, {"key": "disk", "value": "ssd"}] | 2023-07-05 05:58:23 |
|     38021 |       68 |         1 | [{"key": "region", "value": "bj"}, {"key": "disk", "value": "hdd"}] | 2023-07-05 05:58:22 |
|     38021 |        1 |         0 | null                                                                | 2023-07-05 05:58:22 |
+-----------+----------+-----------+---------------------------------------------------------------------+---------------------+
3 rows in set (0.02 sec)

放置规则约束

除了region以外，placement policy 可以利用其它label设置数据保存位置的限制
数据冷热分离是典型应用场景，例如：

create placement policy ssd constraints = "[+disk=ssd]"
create placement policy hdd constraints = "[+disk=hdd]";

/* Advanced Placement Rules */
DROP PLACEMENT POLICY IF EXISTS ssd;
CREATE PLACEMENT POLICY ssd
 CONSTRAINTS="[+disk=ssd]";
DROP PLACEMENT POLICY IF EXISTS hdd;
CREATE PLACEMENT POLICY hdd
 CONSTRAINTS="[+disk=hdd]";
/* Range Partition rpt1 */
DROP TABLE IF EXISTS test.rpt1;
CREATE TABLE test.rpt1 (name int) PARTITION BY RANGE (name) (
 PARTITION p0 VALUES LESS THAN (5) PLACEMENT POLICY = ssd,
 PARTITION p1 VALUES LESS THAN (10) PLACEMENT POLICY = hdd);
/* Data load */
insert into test.rpt1 (name) values (0),(1),(2),(3),(4),(5),(6),
(7),(8),(9);
insert into test.rpt1 (name) select name from test.rpt1;
insert into test.rpt1 (name) select name from test.rpt1;
insert into test.rpt1 (name) select name from test.rpt1;
insert into test.rpt1 (name) select name from test.rpt1;
insert into test.rpt1 (name) select name from test.rpt1;
insert into test.rpt1 (name) select name from test.rpt1;
insert into test.rpt1 (name) select name from test.rpt1;
insert into test.rpt1 (name) select name from test.rpt1;
insert into test.rpt1 (name) select name from test.rpt1;
insert into test.rpt1 (name) select name from test.rpt1;
insert into test.rpt1 (name) select name from test.rpt1;
insert into test.rpt1 (name) select name from test.rpt1;
analyze table test.rpt1;


mysql> SELECT store_id, address, store_state_name, label
    -> FROM information_schema.tikv_store_status;
+----------+---------------------+------------------+---------------------------------------------------------------------+
| store_id | address             | store_state_name | label                                                               |
+----------+---------------------+------------------+---------------------------------------------------------------------+
|        1 | 192.168.16.13:20160 | Up               | null                                                                |
|       68 | 192.168.16.13:20162 | Up               | [{"key": "region", "value": "bj"}, {"key": "disk", "value": "hdd"}] |
|       69 | 192.168.16.13:20161 | Up               | [{"key": "region", "value": "sz"}, {"key": "disk", "value": "ssd"}] |
+----------+---------------------+------------------+---------------------------------------------------------------------+
3 rows in set (0.00 sec)


/* Show status */
/* Can you explain the result? */
 select kvrs.region_id, kvss.store_id, kvrp.is_leader,
kvss.label, kvss.start_ts
 from information_schema.tikv_region_status kvrs
 join information_schema.tikv_region_peers kvrp
 on kvrs.region_id = kvrp.region_id
 join information_schema.tikv_store_status kvss
 on kvrp.store_id = kvss.store_id
 join information_schema.tables t
 on t.table_name = kvrs.table_name
 where t.table_schema='test'
 and t.table_name='rpt1';
+-----------+----------+-----------+---------------------------------------------------------------------+---------------------+
| region_id | store_id | is_leader | label                                                               | start_ts            |
+-----------+----------+-----------+---------------------------------------------------------------------+---------------------+
|     38029 |       69 |         1 | [{"key": "region", "value": "sz"}, {"key": "disk", "value": "ssd"}] | 2023-07-05 05:58:23 |
|     38029 |       68 |         0 | [{"key": "region", "value": "bj"}, {"key": "disk", "value": "hdd"}] | 2023-07-05 05:58:22 |
|     38029 |        1 |         0 | null                                                                | 2023-07-05 05:58:22 |
|     38033 |       69 |         0 | [{"key": "region", "value": "sz"}, {"key": "disk", "value": "ssd"}] | 2023-07-05 05:58:23 |
|     38033 |       68 |         1 | [{"key": "region", "value": "bj"}, {"key": "disk", "value": "hdd"}] | 2023-07-05 05:58:22 |
|     38033 |        1 |         0 | null                                                                | 2023-07-05 05:58:22 |
+-----------+----------+-----------+---------------------------------------------------------------------+---------------------+
6 rows in set (0.04 sec)



/* Check the polices */
mysql> SELECT * FROM information_schema.placement_policies\G;
*************************** 1. row ***************************
           POLICY_ID: 6
        CATALOG_NAME: def
         POLICY_NAME: hdd
      PRIMARY_REGION: 
             REGIONS: 
         CONSTRAINTS: [+disk=hdd]
  LEADER_CONSTRAINTS: 
FOLLOWER_CONSTRAINTS: 
 LEARNER_CONSTRAINTS: 
            SCHEDULE: 
           FOLLOWERS: 2
            LEARNERS: 0
*************************** 2. row ***************************
           POLICY_ID: 5
        CATALOG_NAME: def
         POLICY_NAME: ssd
      PRIMARY_REGION: 
             REGIONS: 
         CONSTRAINTS: [+disk=ssd]
  LEADER_CONSTRAINTS: 
FOLLOWER_CONSTRAINTS: 
 LEARNER_CONSTRAINTS: 
            SCHEDULE: 
           FOLLOWERS: 2
            LEARNERS: 0
*************************** 3. row ***************************
           POLICY_ID: 3
        CATALOG_NAME: def
         POLICY_NAME: east
      PRIMARY_REGION: sz
             REGIONS: sz,bj
         CONSTRAINTS: 
  LEADER_CONSTRAINTS: 
FOLLOWER_CONSTRAINTS: 
 LEARNER_CONSTRAINTS: 
            SCHEDULE: 
           FOLLOWERS: 2
            LEARNERS: 0
*************************** 4. row ***************************
           POLICY_ID: 4
        CATALOG_NAME: def
         POLICY_NAME: west
      PRIMARY_REGION: bj
             REGIONS: bj,sz
         CONSTRAINTS: 
  LEADER_CONSTRAINTS: 
FOLLOWER_CONSTRAINTS: 
 LEARNER_CONSTRAINTS: 
            SCHEDULE: 
           FOLLOWERS: 2
            LEARNERS: 0
4 rows in set (0.00 sec)

ERROR: 
No query specified
数哥
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
专栏目录
[中文翻译 by Hangzhi] High Performance TiDB 7_ transactions1
08-04
In a TiDB cluster, there are three kinds of node: TiDB, TiKV, and PD.When we’re
TiDB测试_201808201
08-03
TiDB 集群主要分为三个组件：TiDB Server 负责接收 SQL 请求，处理 SQL 相关的逻辑，并通过 PD 找到存储计算所需数据的 TiKV 地址，
数据库｜从源码分析TiUP如何判断TiDB集群状态
在数字化道路无限探索
06-28 238
tiup cluster display 执行流程代码详解
tiup cluster display 执行流程代码详解
TiDB 社区干货传送门
04-06 151
作者： Hacker_loCdZ5zu 原文来源： https://tidb.net/blog/54da9e58 ...
同城多数据中心部署 TiDB
weixin_42241611的博客
07-20 510
作为NewSQL数据库，TiDB兼顾了传统关系型数据库的优秀特性、NoSQL数据库可扩展性以及跨数据中心场景下的高可用。本文档旨在介绍同城多数据中心部署TiDB方案。
TiDB 6.0 Placement Rules In SQL 使用实践
TiDB_PingCAP 的博客
08-04 400
TiDB 6.0 版本正式提供了基于 SQL 接口的数据放置框架（Placement Rules in SQL）， 特性用于通过 SQL 接口配置数据在 TiKV 集群中的放置位置。通过该功能，用户可以将表和分区指定部署至不同的地域、机房、机柜、主机。适用场景包括低成本优化数据高可用策略、保证本地的数据副本可用于本地 Stale Read 读取、遵守数据本地要求等。...
033、TiDB特性_AUTO_INCREMENT
细致-专业-实操
07-10 1092
AUTO_INCREMENT: 是⽤于⾃动填充默认字段值的属性。注意：这个会报错，提示插入的是重复值。auto_increment 属性。
034、TiDB特性_AUTO_RANDOM
细致-专业-实操
07-10 1079
如以上语句，由于未指定主键列的值（ a 列），TiDB 会使⽤连续⾃增的⾏值作为⾏ ID，可能导致单个 TiKV 节点上产⽣写⼊热点，进⽽影响对外提供服务的性能。通过随机的产生主键，让数据分布在不同的region上。若要使⽤⼀个不同的 shard bits 的数量，可以在 AUTO_RANDOM 后⾯加⼀对括号，并在括号中指定想要的 shard bits 数量。该⾏值在⼆进制形式下，除去符号位的最⾼五位（称为 shard bits）由当前事务的开始时间决定，剩下的位数按照⾃增的顺序分配。
045、TiDB特性_读取数据副本
细致-专业-实操
07-16 350
当系统中存在读取热点 Region 导致 leader 资源紧张成为整个系统读取瓶颈时，启用 Follower Read 功能可明显降低 leader 的负担，并且通过在多个 follower 之间均衡负载，显著地提升整体系统的吞吐能力。由于follower region可能不是最新数据，此时又想通过查询follower的region来降低热点的频率，此时可以通过设置TIDB_BOUNDED_STALENESS 来读取指定时间范围当中的最新数据。该事务将会基于所提供的历史时间来读取历史数据。
042、TiDB特性_系统表的使用
细致-专业-实操
07-15 366
查询deadlocks 表，来确定死锁情况。
035、TiDB特性_没有主键的随机ID
细致-专业-实操
07-11 608
【代码】035、TiDB特性_没有主键的随机ID。
101_TiDB+快速起步_.zip
08-20
101_TiDB 快速起步_练习指南 以及 101_TiDB+快速起步_学生指南.pdf 官方出品
tidb技术分享.pptx
03-23
tidb的简介、安装部署、Sql操作等
TiDB体系架构思维导图
01-04
TiDB体系架构思维导图
036、TiDB特性_临时表
细致-专业-实操
07-11 679
用户可通过 CREATE GLOBAL TEMPORARY TABLE 语句创建全局临时表，语句末尾要加上 ON COMMIT DELETE ROWS。可通过 DROP TABLE 或 DROP GLOBAL TEMPORARY TABLE 语句删除全局临时表。• 用户可通过 CREATE TEMPORARY TABLE 语句创建本地临时表，通过 DROP TABLE 或 DROP TEMPORARY TABLE 语句删除本地临时表。
TiDB学习8：TiDB6.0新特性
zj88189748的专栏
05-30 1013
内存悲观锁：在内存中修改数据的同时，只把锁信息写到Leader节点的TiKV缓存中，不写到磁盘中，并且不复制给其他节点，此时Leader节点宕机会造成锁丢失，事务回滚。悲观锁：在内存中修改数据的同时，把锁写入lock列簇中，让其他事务能看到锁信息，网络和磁盘IO都有负载。乐观锁：在commit的时候，才做prewrite，加锁，在此之前其他事务不知道这个数据上有锁。Placement Rules in SQL 的使用 -步骤 1。Placement Rules in SQL的使用-步骤 3。
TiDB-从0到1-MVCC
MZZHAO23的博客
05-29 919
TiDB-从0到1-MVCC
TiDB学习9：Ti Cloud简介
最新发布
zj88189748的专栏
05-30 738
TiDB Cloud 是一个功能齐全的数据库即服务或(DBaaS，DataBase as a Service)Iaas：Infrastructure as a Service，基础设施即服务，假设做一个论坛，不用云的话，就自己买服务器、操作系统、数据库、所有的软件、自己写代码等等把这个论坛做出来，人力成本和时间成本很高，如果用IaaS，那么服务器硬件、网络、存储等不用管了，直接自己就可以开发程序了，云服务厂商拥有并管理那些运行您软件的硬件(服务器、网络、存储等等)Paas。
TiDB-从0到1-分布式事务
MZZHAO23的博客
05-28 1135
TiDB-从0到1-分布式事务介绍
tidb auto_increment
06-09
TiDB 的 auto_increment 是用来生成自增主键的功能。在 TiDB 中，定义一个自增主键的方式与 MySQL 类似，只需要在创建表的时候在主键字段的类型后面加上 AUTO_INCREMENT 关键字即可。 例如，创建一个名为 user 的表，其中 id 字段是自增主键： ``` CREATE TABLE user ( id INT NOT NULL AUTO_INCREMENT, name VARCHAR(50), age INT, PRIMARY KEY (id) ); ``` 在 TiDB 中，自增主键的实现是基于 TiDB 的分布式特性，每个 TiDB 节点都会维护一个自增 ID 的区间，当需要生成新的自增 ID 时，TiDB 会从本地的自增 ID 区间内获取一个 ID，并将这个 ID 的最大值同步到 PD 集群中，以保证全局唯一性。这样就可以避免在分布式环境下出现多个节点生成相同的自增 ID 的问题。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

数哥

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值