关于文章 sql

java nosql orientdb sql

orientdb的restfulapi调用

orientdb

本来想用 python 版本的驱动 但是 - - 已经有好久没更新了

只好用http的

    • 看起来还行
import requests
import json
class SqlSdk():
    def __init__(self,url="http://192.168.1.91:2480",name="free",password="free",database="rpg"):
        self.url = url
        self.name = name
        self.password = password
        self.database = database
        self.auth = (self.name,self.password)
    def exec(self,sql,params=[]):
        return requests.post(f"{self.url}/command/{self.database}/sql",auth=self.auth,data=json.dumps({
            "command": sql,
            "parameters": params
        }))

以下为官方文档的


search: keywords: ['SQL']


Introduction

When it comes to query languages, SQL is the most widely recognized standard. The majority of developers have experience and are comfortable with SQL. For this reason Orient DB uses SQL as its query language and adds some extensions to enable graph functionality. There are a few differences between the standard SQL syntax and that supported by OrientDB, but for the most part, it should feel very natural. The differences are covered in the OrientDB SQL dialect section of this page.

If you are looking for the most efficient way to traverse a graph, we suggest to use the SQL-Match instead.

Many SQL commands share the WHERE condition. Keywords and class names in OrientDB SQL are case insensitive. Field names and values are case sensitive. In the following examples keywords are in uppercase but this is not strictly required.

If you are not yet familiar with SQL, we suggest you to get the course on KhanAcademy.

For example, if you have a class MyClass with a field named id, then the following SQL statements are equivalent:

SELECT FROM MyClass WHERE id = 1
select from myclass where id = 1

The following is NOT equivalent. Notice that the field name 'ID' is not the same as 'id'.

SELECT FROM MyClass WHERE ID = 1

Automatic usage of indexes

OrientDB allows you to execute queries against any field, indexed or not-indexed. The SQL engine automatically recognizes if any indexes can be used to speed up execution. You can also query any indexes directly by using INDEX:<index-name> as a target. Example:

SELECT FROM INDEX:myIndex WHERE key = 'Jay'

Extra resources

OrientDB SQL dialect

OrientDB supports SQL as a query language with some differences compared with SQL. Orient Technologies decided to avoid creating Yet-Another-Query-Language. Instead we started from familiar SQL with extensions to work with graphs. We prefer to focus on standards.

If you want learn SQL, there are many online courses such as: - Online course Introduction to Databases by Jennifer Widom from Stanford university - Introduction to SQL at W3 Schools - Beginner guide to SQL - SQLCourse.com - YouTube channel Basic SQL Training by Joey Blue

To know more, look to OrientDB SQL Syntax.

Or order any book like these

No JOINs

The most important difference between OrientDB and a Relational Database is that relationships are represented by LINKS instead of JOINs.

For this reason, the classic JOIN syntax is not supported. OrientDB uses the "dot (.) notation" to navigate LINKS. Example 1 : In SQL you might create a join such as:

SELECT *
FROM Employee A, City B
WHERE A.city = B.id
AND B.name = 'Rome'

In OrientDB, an equivalent operation would be:

SELECT * FROM Employee WHERE city.name = 'Rome'

This is much more straight forward and powerful! If you use multiple JOINs, the OrientDB SQL equivalent will be an even larger benefit. Example 2: In SQL you might create a join such as:

SELECT *
FROM Employee A, City B, Country C,
WHERE A.city = B.id
AND B.country = C.id
AND C.name = 'Italy'

In OrientDB, an equivalent operation would be:

SELECT * FROM Employee WHERE city.country.name = 'Italy'

Projections

In SQL, projections are mandatory and you can use the star character * to include all of the fields. With OrientDB this type of projection is optional. Example: In SQL to select all of the columns of Customer you would write:

SELECT * FROM Customer

In OrientDB, the * is optional:

SELECT FROM Customer

See SQL projections

DISTINCT

In OrientDB v 3.0 you can use DISTINCT keyword exactly as in a relational database:

SELECT DISTINCT name FROM City

Until v 2.2, DISTINCT keyword was not allowed; there was a DISTINCT() function instead, with limited capabilities

//legacy

SELECT DISTINCT(name) FROM City

HAVING

OrientDB does not support the HAVING keyword, but with a nested query it's easy to obtain the same result. Example in SQL:

SELECT city, sum(salary) AS salary
FROM Employee
GROUP BY city
HAVING salary > 1000

This groups all of the salaries by city and extracts the result of aggregates with the total salary greater than 1,000 dollars. In OrientDB the HAVING conditions go in a select statement in the predicate:

SELECT FROM ( SELECT city, SUM(salary) AS salary FROM Employee GROUP BY city ) WHERE salary > 1000

Select from multiple targets

OrientDB allows only one class (classes are equivalent to tables in this discussion) as opposed to SQL, which allows for many tables as the target. If you want to select from 2 classes, you have to execute 2 sub queries and join them with the UNIONALL function:

SELECT FROM E, V

In OrientDB, you can accomplish this with a few variable definitions and by using the expand function to the union:

SELECT EXPAND( $c ) LET $a = ( SELECT FROM E ), $b = ( SELECT FROM V ), $c = UNIONALL( $a, $b )
mysql newsql nosql sql tidb

TiDB 权限管理

TiDB 权限管理


title: 权限管理 category: compatibility


权限管理

TiDB的权限管理系统是按照MySQL的权限管理进行实现,大部分的MySQL的语法和权限类型都是支持的。如果发现行为跟MySQL不一致的地方,欢迎报告issue。

注意:当前版本的权限功能并没有默认开启,需要添加启动参数指定: ./tidb-server -privilege=true 如果不指定参数,权限检查不会生效。将来去掉这个参数(预计RC3)并默认启用权限检查。

1. 用户账户操作

更改密码

set password for 'root'@'%' = 'xxx';

添加用户

create user 'test'@'127.0.0.1' identified by 'xxx';

用户名是大小写敏感的。host则支持模糊匹配,比如:

create user 'test'@'192.168.10.%';

允许test用户从192.168.10子网的任何一个主机登陆。

如果没有指定host,则默认是所有IP均可登陆。如果没有指定密码,默认为空:

create user 'test';

等价于

create user 'test'@'%' identified by '';

删除用户

drop user 'test'@'%';

这个操作会清除用户在mysql.user表里面的记录项,并且清除在授权表里面的相关记录。

忘记root密码

使用一个特殊的启动参数启动TiDB(需要root权限):

sudo ./tidb-server -skip-grant-table=true

这个参数启动,TiDB会跳过权限系统,然后使用root登陆以后修改密码:

mysql -h 127.0.0.1 -P 4000 -u root

2. 权限相关操作

授予权限

授予xxx用户对数据库test的读权限:

grant Select on test.* to 'xxx'@'%';

为test用户授予所有数据库,全部权限:

grant all privileges on *.* to 'xxx'@'%';

如果grant的目标用户不存在,TiDB会自动创建用户。

mysql> select * from mysql.user where user='xxxx';
Empty set (0.00 sec)

mysql> grant all privileges on test.* to 'xxxx'@'%' identified by 'yyyyy';
Query OK, 0 rows affected (0.00 sec)

mysql> select user,host from mysql.user where user='xxxx';
+------|------+
| user | host |
+------|------+
| xxxx | %    |
+------|------+
1 row in set (0.00 sec)

例子中xxxx@%就是自动添加进去的用户。

grant对于数据库或者表的授权,不检查数据库或表是否存在。

mysql> select * from test.xxxx;
ERROR 1146 (42S02): Table 'test.xxxx' doesn't exist

mysql> grant all privileges on test.xxxx to xxxx;
Query OK, 0 rows affected (0.00 sec)

mysql> select user,host from mysql.tables_priv where user='xxxx';
+------|------+
| user | host |
+------|------+
| xxxx | %    |
+------|------+
1 row in set (0.00 sec)

grant可以模糊匹配地授予数据库和表

mysql> grant all privileges on `te%`.* to genius;
Query OK, 0 rows affected (0.00 sec)

mysql> select user,host,db from mysql.db where user='genius';
+--------|------|-----+
| user   | host | db  |
+--------|------|-----+
| genius | %    | te% |
+--------|------|-----+
1 row in set (0.00 sec)

这个例子中通过%模糊匹配,所有te开头的数据库,都被授予了权限。

收回权限

revoke语句与grant对应:

revoke all privileges on `test`.* from 'genius'@'localhost';

注意revoke收回权限时只做精确匹配,若找不到记录则报错。而grant授予权限时可以使用模糊匹配。

mysql> revoke all privileges on `te%`.* from 'genius'@'%';
ERROR 1141 (42000): There is no such grant defined for user 'genius' on host '%'

关于模糊匹配和转义,字符串和identifier

mysql> grant all privileges on `te\%`.* to 'genius'@'localhost'; Query OK, 0 rows affected (0.00 sec)

这个例子是精确匹配名叫te%的数据库,注意到用了\转义字符。

以单引号包含的,是一个字符串。以反引号包含的,是一个identifier。注意下面区别:

``` mysql> grant all privileges on 'test'. to 'genius'@'localhost'; ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ''test'. to 'genius'@'localhost'' at line 1

mysql> grant all privileges on test.* to 'genius'@'localhost'; Query OK, 0 rows affected (0.00 sec) ```

如果一些特殊的关键字想做为表名,可以用反引号包含起来。比如:

mysql> create table `select` (id int); Query OK, 0 rows affected (0.27 sec)

查看为用户分配的权限

show grant语句可以查看为用户分配了哪些权限。

show grants for 'root'@'%';

更精确的方式,可以通过直接查看授权表的数据实现。比如想知道,test@%该用户是否拥有对db1.t的Insert权限。

先查看该用户是否拥有全局Insert权限:

select Insert from mysql.user where user='test' and host='%';

如果没有,再查看该用户是否拥有db1数据库级别的Insert权限:

select Insert from mysql.db where user='test' and host='%';

如果仍然没有,则继续判断是否拥有db1.t这张表的Insert权限:

select tables_priv from mysql.tables_priv where user='test' and host='%' and db='db1';

3. 权限系统的实现

授权表

有几张系统表是非常特殊的表,权限相关的数据全部存储在这几张表内。

  • mysql.user 用户账户,全局权限
  • mysql.db 数据库级别的权限
  • mysql.tables_priv 表级别的权限
  • mysql.columns_priv 列级别的权限

这几张表包含了数据的生效范围和权限信息。例如,mysql.user表的部分数据:

mysql> select User,Host,Select_priv,Insert_priv from mysql.user limit 1;
+------|------|-------------|-------------+
| User | Host | Select_priv | Insert_priv |
+------|------|-------------|-------------+
| root | %    | Y           | Y           |
+------|------|-------------|-------------+
1 row in set (0.00 sec)

这条记录中,Host和User决定了root用户从任意主机(%)发送过来的连接请求可以被接受,而Select_privInsert_priv表示用户拥有全局的Select和Insert权限。mysql.user这张表里面的生效范围是全局的。

mysql.db表里面包含的Host和User决定了用户可以访问哪些数据库,权限列的生效范围是数据库。

理论上,所有权限管理相关的操作,都可以通过直接对授权表的CRUD操作完成。

实现层面其实也只是包装了一层语法糖。例如删除用户会执行:

delete from mysql.user where user='test';

但是不推荐用户手动修改授权表。

连接验证

当客户端发送连接请求时,TiDB服务器会对登陆操作进行验证。验证过程先检查mysql.user表,当某条记录的User和Host和连接请求匹配上了,再去验证Password。用户身份基于两部分信息,发起连接的客户端的Host,以及用户名User。如果User不为空,则用户名必须精确匹配。

User+Host可能会匹配user表里面多行,为了处理这种情况,user表的行是排序过的,客户端连接时会依次去匹配,并使用首次匹配到的那一行做权限验证。排序是按Host在前,User在后。

请求验证

连接成功之后,请求验证会检测执行操作是否拥有足够的权限。

对于数据库相关请求(INSERT,UPDATE),先检查mysql.user表里面的用户全局权限,如果权限够,则直接可以访问。如果全局权限不足,则再检查mysql.db表。

user表的权限是全局的,并且不管默认数据库是哪一个。比如user里面有DELETE权限,任何一行,任何的表,任何的数据库。

db表里面,User为空是匹配匿名用户,User里面不能有通配符。Host和Db列里面可以有%_,可以模式匹配。

userdb读到内存也是排序的。

tables_privcolumns_priv 中使用%是类似的,但是在Db, Table_name, Column_name 这些列不能包含%。加载进来时排序也是类似的。

生效时机

TiDB启动时,将一些权限检查的表加载到内存,之后使用缓存的数据来验证权限。系统会周期性的将授权表从数据库同步到缓存,生效则是由同步的周期决定,目前这个值设定的是5分钟。

修改了授权表,如果需要立即生效,可以手动调用:

flush privileges;

4. 限制和约束

一些使用频率偏低的权限当前版本的实现中还未做检查,比如FILE/USAGE/SHUTDOWN/EXECUTE/PROCESS/INDEX等等,未来会陆续完善。

现阶段对权限的支持还没有做到column级别。

mysql newsql nosql pg sql tidb

TiDB 命令行参数

TiDB 命令行参数


title: PD Control 使用说明 category: monitoring


PD Control 使用说明

PD Control 是 PD 的命令行工具,用于获取集群状态信息和调整集群。

源码编译

  1. Go Version 1.7 以上
  2. 在 PD 项目根目录使用 make 命令进行编译,生成 bin/pd-ctl

简单例子

单命令模式:

./pd-ctl store -d -u http://127.0.0.1:2379

交互模式:

./pd-ctl -u http://127.0.0.1:2379

使用环境变量:

export PD_ADDR=http://127.0.0.1:2379
./pd-ctl

命令行参数(flags)

--pd,-u

  • 指定 PD 的地址
  • 默认地址: http://127.0.0.1:2379
  • 环境变量: PD_ADDR

--detach,-d

  • 使用单命令行模式(不进入 readline )
  • 默认值: false

命令(command)

store [delete] \<store_id>

用于显示 store 信息或者删除指定 store。

示例:

>> store            // 显示所有 store 信息
{
  "count": 3,
  "stores": [...]
}
>> store 1          // 获取 store id 为 1 的 store
  ......
>> store delete 1   // 下线 store id 为 1 的 store
  ......

region \<region_id>

用于显示 region 信息。

示例:

>> region                               // 显示所有 region 信息
{
  "count": 1,
  "regions": [......]
}

>> region 2                             // 显示 region id 为 2 的信息
{
  "region": {
      "id": 2,
      ......
  }
  "leader": {
      ......
  }
}

region key [--format=raw|pb|proto|protobuf] \<key>

用于查询某个 key 在哪个 region 上,支持 raw 和 protobuf 格式。

Raw 格式(默认)示例:

>> region key abc
{
  "region": {
    "id": 2,
    ......
  }
}

Protobuf 格式示例:

>> region key --format=pb t\200\000\000\000\000\000\000\377\035_r\200\000\000\000\000\377\017U\320\000\000\000\000\000\372
{
  "region": {
    "id": 2,
    ......
  }
}

member [leader | delete]

用于显示 PD 成员信息或删除指定成员。

示例:

>> member                               // 显示所有成员的信息
{
  "members": [......]
}
>> member leader                        // 显示 leader 的信息
{
  "name": "pd",
  "addr": "http://192.168.199.229:2379",
  "id": 9724873857558226554
}
>> member delete pd2                    // 下线 "pd2"
Success!

config [show | set \<option> \<value>]

用于显示或调整配置信息。

示例:

>> config show                             // 显示 config 的信息
{
  "max-snapshot-count": 3,
  "max-store-down-time": "1h",
  "leader-schedule-limit": 8,
  "region-schedule-limit": 4,
  "replica-schedule-limit": 8,
}

通过调整 leader-schedule-limit 可以控制同时进行 leader 调度的任务个数。 这个值主要影响 leader balance 的速度,值越大调度得越快,设置为 0 则关闭调度。 Leader 调度的开销较小,需要的时候可以适当调大。

>> config set leader-schedule-limit 4       // 最多同时进行 4 个 leader 调度

通过调整 region-schedule-limit 可以控制同时进行 region 调度的任务个数。 这个值主要影响 region balance 的速度,值越大调度得越快,设置为 0 则关闭调度。 Region 调度的开销较大,所以这个值不宜调得太大。

>> config set region-schedule-limit 2       // 最多同时进行 2 个 region 调度

通过调整 replica-schedule-limit 可以控制同时进行 replica 调度的任务个数。 这个值主要影响节点挂掉或者下线的时候进行调度的速度,值越大调度得越快,设置为 0 则关闭调度。 Replica 调度的开销较大,所以这个值不宜调得太大。

>> config set replica-schedule-limit 4      // 最多同时进行 4 个 replica 调度

operator [show | add | remove]

用于显示和控制调度操作。

示例:

>> operator show                            // 显示所有的 operators
>> operator show admin                      // 显示所有的 admin operators
>> operator show leader                     // 显示所有的 leader operators
>> operator show region                     // 显示所有的 region operators
>> operator add transfer-leader 1 2         // 把 region 1 的 leader 调度到 store 2
>> operator add transfer-region 1 2 3 4     // 把 region 1 调度到 store 2,3,4
>> operator add transfer-peer 1 2 3         // 把 region 1 在 store 2 上的副本调度到 store 3
>> operator remove 1                        // 把 region 1 的调度操作删掉

scheduler [show | add | remove]

用于显示和控制调度策略。

示例:

>> scheduler show                             // 显示所有的 schedulers
>> scheduler add grant-leader-scheduler 1     // 把 store 1 上的所有 region 的 leader 调度到 store 1
>> scheduler add evict-leader-scheduler 1     // 把 store 1 上的所有 region 的 leader 从 store 1 调度出去
>> scheduler add shuffle-leader-scheduler     // 随机交换不同 store 上的 leader
>> scheduler add shuffle-region-scheduler     // 随机调度不同 store 上的 region
>> scheduler remove grant-leader-scheduler-1  // 把对应的 scheduler 删掉

title: 参数解释 category: deployment


参数解释

TiDB

--store

  • 用来指定 TiDB 底层使用的存储引擎
  • 默认: "goleveldb"
  • 你可以选择 "memory", "goleveldb", "BoltDB" 或者 "TiKV"。(前面三个是本地存储引擎,而 TiKV 是一个分布式存储引擎)
  • 例如,如果我们可以通过 tidb-server --store=memory 来启动一个纯内存引擎的 TiDB

--path

  • 对于本地存储引擎 "goleveldb", "BoltDB" 来说,path 指定的是实际的数据存放路径
  • 对于 "memory" 存储引擎来说,path 不用设置
  • 对于 "TiKV" 存储引擎来说,path 指定的是实际的 PD 地址。假设我们在 192.168.100.113:2379, 192.168.100.114:2379 和 192.168.100.115:2379 上面部署了 PD,那么 path 为 "192.168.100.113:2379, 192.168.100.114:2379, 192.168.100.115:2379"
  • 默认: "/tmp/tidb"

-L

  • Log 级别
  • 默认: "info"
  • 我们能选择 debug, info, warn, error 或者 fatal

--log-file

  • Log 文件
  • 默认: ""
  • 如果没设置这个参数,log 会默认输出到 "stderr",如果设置了,log 就会输出到对应的文件里面,在每天凌晨,log 会自动轮转使用一个新的文件,并且将以前的文件改名备份

--host

  • TiDB 服务监听 host
  • 默认: "0.0.0.0"
  • TiDB 服务会监听这个 host
  • 0.0.0.0 默认会监听所有的网卡 address。如果有多块网卡,可以指定对外提供服务的网卡,譬如192.168.100.113

-P

  • TiDB 服务监听端口
  • 默认: "4000"
  • TiDB 服务将会使用这个端口接受 MySQL 客户端发过来的请求

--status

  • TiDB 服务状态监听端口
  • 默认: "10080"
  • 这个端口是为了展示 TiDB 内部数据用的。包括 prometheus 统计 以及 pprof
  • Prometheus 统计可以通过 "http://host:status_port/metrics" 访问
  • Pprof 数据可以通过 "http://host:status_port/debug/pprof" 访问

--lease

  • Schema 的租约时间,单位:秒
  • 默认: "1"
  • Schema 的 lease 主要用在 online schema changes 上面。这个值会影响到实际的 DDL 语句的执行时间。千万不要随便改动这个值,除非你能知道相关的内部机制

--socket

  • TiDB 服务使用 unix socket file 方式接受外部连接
  • 默认: ""
  • 譬如我们可以使用 "/tmp/tidb.sock" 来打开 unix socket file

--perfschema

  • 使用 true/false 来打开或者关闭性能 schema
  • 默认: false
  • 值可以是 (true) or (false)。性能 Schema 可以帮助我们在运行时检测内部的执行情况。可以通过 performance schema 获取更多信息。但需要注意,开启性能 Schema,会影响 TiDB 的性能

--privilege

  • 使用 true/false 来打开或者关闭权限功能(用于开发调试)
  • 默认: true
  • 值可以是(true) or (false)。当前版本的权限控制还在完善中,将来会去掉此选项

--skip-grant-table

  • 允许任何人不带密码连接,并且所有的操作不检查权限
  • 默认: false
  • 值可以是(true) or (false)。启用此选项需要有本机的root权限,一般用于忘记密码时重置

--report-status

  • 打开 (true) 或者关闭 (false) 服务状态监听端口
  • 默认: true
  • 值可以为 (true) 或者 (false). (true) 表明我们开启状态监听端口。 (false) 表明关闭

--metrics-addr

  • Prometheus Push Gateway 地址
  • 默认: ""
  • 如果为空,TiDB 不会将统计信息推送给 Push Gateway

--metrics-intervel

  • 推送统计信息到 Prometheus Push Gateway 的时间间隔
  • 默认: 15s
  • 设置为 0 表明不推送统计信息给 Push Gateway

Placement Driver (PD)

-L

  • Log 级别
  • 默认: "info"
  • 我们能选择 debug, info, warn, error 或者 fatal

--log-file

  • Log 文件
  • 默认: ""
  • 如果没设置这个参数,log 会默认输出到 "stderr",如果设置了,log 就会输出到对应的文件里面,在每天凌晨,log 会自动轮转使用一个新的文件,并且将以前的文件改名备份

--config

  • 配置文件
  • 默认: ""
  • 如果你指定了配置文件,PD 会首先读取配置文件的配置。然后如果对应的配置在命令行参数里面也存在,PD 就会使用命令行参数的配置来覆盖配置文件里面的

--name

  • 当前 PD 的名字
  • 默认: "pd"
  • 如果你需要启动多个 PD,一定要给 PD 使用不同的名字

--data-dir

  • PD 存储数据路径
  • 默认: "default.${name}"

--client-urls

  • 处理客户端请求监听 URL 列表
  • 默认: "http://127.0.0.1:2379"
  • 如果部署一个集群,--client-urls 必须指定当前主机的 IP 地址,例如 "http://192.168.100.113:2379",如果是运行在 docker 则需要指定为 "http://0.0.0.0:2379"

--advertise-client-urls

  • 对外客户端访问 URL 列表
  • 默认: ${client-urls}
  • 在某些情况下,譬如 docker,或者 NAT 网络环境,客户端并不能通过 PD 自己监听的 client URLs 来访问到 PD,这时候,你就可以设置 advertise urls 来让客户端访问
  • 例如,docker 内部 IP 地址为 172.17.0.1,而宿主机的 IP 地址为 192.168.100.113 并且设置了端口映射 -p 2379:2379,那么可以设置为 --advertise-client-urls="http://192.168.100.113:2379",客户端可以通过 http://192.168.100.113:2379 来找到这个服务

--peer-urls

  • 处理其他 PD 节点请求监听 URL 列表。
  • default: "http://127.0.0.1:2380"
  • 如果部署一个集群,--peer-urls 必须指定当前主机的 IP 地址,例如 "http://192.168.100.113:2380",如果是运行在 docker 则需要指定为 "http://0.0.0.0:2380"

--advertise-peer-urls

  • 对外其他 PD 节点访问 URL 列表。
  • 默认: ${peer-urls}
  • 在某些情况下,譬如 docker,或者 NAT 网络环境,其他节点并不能通过 PD 自己监听的 peer URLs 来访问到 PD,这时候,你就可以设置 advertise urls 来让其他节点访问
  • 例如,docker 内部 IP 地址为 172.17.0.1,而宿主机的 IP 地址为 192.168.100.113 并且设置了端口映射 -p 2380:2380,那么可以设置为 --advertise-peer-urls="http://192.168.100.113:2380",其他 PD 节点可以通过 http://192.168.100.113:2380 来找到这个服务

--initial-cluster

  • 初始化 PD 集群配置。
  • 默认: "{name}=http://{advertise-peer-url}"
  • 例如,如果 name 是 "pd", 并且 advertise-peer-urls 是 "http://192.168.100.113:2380", 那么 initial-cluster 就是 pd=http://192.168.100.113:2380
  • 如果你需要启动三台 PD,那么 initial-cluster 可能就是 pd1=http://192.168.100.113:2380, pd2=http://192.168.100.114:2380, pd3=192.168.100.115:2380

--join

  • 动态加入 PD 集群
  • 默认: ""
  • 如果你想动态将一台 PD 加入集群,你可以使用 --join="${advertise-client-urls}"advertise-client-url 是当前集群里面任意 PD 的 advertise-client-url,你也可以使用多个 PD 的,需要用逗号分隔

TiKV

TiKV 在命令行参数上面支持一些可读性好的单位转换。

  • 文件大小(以 bytes 为单位): KB, MB, GB, TB, PB(也可以全小写)
  • 时间(以毫秒为单位): ms, s, m, h

-A, --addr

  • TiKV 监听地址
  • 默认: "127.0.0.1:20160"
  • 如果部署一个集群,--addr 必须指定当前主机的 IP 地址,例如 "http://192.168.100.113:20160",如果是运行在 docker 则需要指定为 "http://0.0.0.0:20160"

--advertise-addr

  • TiKV 对外访问地址。
  • 默认: ${addr}
  • 在某些情况下,譬如 docker,或者 NAT 网络环境,客户端并不能通过 TiKV 自己监听的地址来访问到 TiKV,这时候,你就可以设置 advertise addr 来让 客户端访问
  • 例如,docker 内部 IP 地址为 172.17.0.1,而宿主机的 IP 地址为 192.168.100.113 并且设置了端口映射 -p 20160:20160,那么可以设置为 --advertise-addr="192.168.100.113:20160",客户端可以通过 192.168.100.113:20160 来找到这个服务

-L, --log

  • Log 级别
  • 默认: "info"
  • 我们能选择 trace, debug, info, warn, error, 或者 off

--log-file

  • Log 文件
  • 默认: ""
  • 如果没设置这个参数,log 会默认输出到 "stderr",如果设置了,log 就会输出到对应的文件里面,在每天凌晨,log 会自动轮转使用一个新的文件,并且将以前的文件改名备份

-C, --config

  • 配置文件
  • 默认: ""
  • 如果你指定了配置文件,TiKV 会首先读取配置文件的配置。然后如果对应的配置在命令行参数里面也存在,TiKV 就会使用命令行参数的配置来覆盖配置文件里面的

--data-dir

  • TiKV 数据存储路径
  • 默认: "/tmp/tikv/store"

--capacity

  • TiKV 存储数据的容量
  • 默认: 0 (无限)
  • PD 需要使用这个值来对整个集群做 balance 操作。(提示:你可以使用 10GB 来替代 10737418240,从而简化参数的传递)

--pd

  • PD 地址列表。
  • 默认: ""
  • TiKV 必须使用这个值连接 PD,才能正常工作。使用逗号来分隔多个 PD 地址,例如: 192.168.100.113:2379, 192.168.100.114:2379, 192.168.100.115:2379
kv mysql newsql nosql sql

TiDB Binary 部署方案详解

TiDB Binary 部署方案详解


title: TiDB Binary 部署方案详解 category: deployment


# TiDB Binary 部署方案

## 概述

一个完整的 TiDB 集群包括 PD,TiKV 以及 TiDB。启动顺序依次是 PD,TiKV 以及 TiDB。

阅读本章前,请先确保阅读 TiDB 整体架构部署建议

快速了解和试用 TiDB,推荐使用单节点方式快速部署

功能性测试 TiDB,推荐使用功能性测试部署

生产环境使用 TiDB,推荐使用多节点集群模式部署

## 下载官方 Binary

### Linux (CentOS 7+, Ubuntu 14.04+)

```bash # 下载压缩包 wget http://download.pingcap.org/tidb-latest-linux-amd64.tar.gz wget http://download.pingcap.org/tidb-latest-linux-amd64.sha256

# 检查文件完整性,返回 ok 则正确 sha256sum -c tidb-latest-linux-amd64.sha256

# 解开压缩包 tar -xzf tidb-latest-linux-amd64.tar.gz cd tidb-latest-linux-amd64 ``` ### CentOS 6

注意:我们大部分开发和测试都是在 CentOS 7+, Ubuntu 14.04+ 上进行,CentOS 6 上面并没有经过严格测试,所以不推荐在 CentOS 6 上部署 TiDB 集群

```bash # 下载 CentOS6 压缩包 wget http://download.pingcap.org/tidb-latest-linux-amd64-centos6.tar.gz wget http://download.pingcap.org/tidb-latest-linux-amd64-centos6.sha256

# 检查文件完整性,返回 ok 则正确 sha256sum -c tidb-latest-linux-amd64-centos6.sha256

# 解开压缩包 tar -xzf tidb-latest-linux-amd64-centos6.tar.gz cd tidb-latest-linux-amd64-centos6 ```

## 单节点方式快速部署

我们可以在单机上面,运行和测试 TiDB 集群,请按如下步骤依次启动 PD,TiKV,TiDB:

  1. 启动 PD

    bash ./bin/pd-server --data-dir=pd \ --log-file=pd.log

  2. 启动 TiKV

    bash ./bin/tikv-server --pd="127.0.0.1:2379" \ --data-dir=tikv \ --log-file=tikv.log

  3. 启动 TiDB

    bash ./bin/tidb-server --store=tikv \ --path="127.0.0.1:2379" \ --log-file=tidb.log

  4. 使用官方的 mysql 客户端连接 TiDB

    bash mysql -h 127.0.0.1 -P 4000 -u root -D test

## 多节点集群模式部署 在生产环境中,我们推荐多节点部署 TiDB 集群,首先请参考部署建议

这里我们使用六个节点,部署三个 PD,三个 TiKV,以及一个 TiDB,各个节点以及所运行服务信息如下:

Name Host IP Services
node1 192.168.199.113 PD1, TiDB
node2 192.168.199.114 PD2
node3 192.168.199.115 PD3
node4 192.168.199.116 TiKV1
node5 192.168.199.117 TiKV2
node6 192.168.199.118 TiKV3

请按如下步骤 依次启动 PD 集群,TiKV 集群以及 TiDB:

  1. 在 node1,node2,node3 依次启动 PD

    ```bash ./bin/pd-server --name=pd1 \ --data-dir=pd1 \ --client-urls="http://192.168.199.113:2379" \ --peer-urls="http://192.168.199.113:2380" \ --initial-cluster="pd1=http://192.168.199.113:2380" \ --log-file=pd.log

    ./bin/pd-server --name=pd2 \ --data-dir=pd2 \ --client-urls="http://192.168.199.114:2379" \ --peer-urls="http://192.168.199.114:2380" \ --join="http://192.168.199.113:2379" \ --log-file=pd.log

    ./bin/pd-server --name=pd3 \ --data-dir=pd3 \ --client-urls="http://192.168.199.115:2379" \ --peer-urls="http://192.168.199.115:2380" \ --join="http://192.168.199.113:2379" \ --log-file=pd.log ```

  2. 在 node4,node5,node6 启动 TiKV

    ```bash ./bin/tikv-server --pd="192.168.199.113:2379,192.168.199.114:2379,192.168.199.115:2379" \ --addr="192.168.199.116:20160" \ --data-dir=tikv1 \ --log-file=tikv.log

    ./bin/tikv-server --pd="192.168.199.113:2379,192.168.199.114:2379,192.168.199.115:2379" \ --addr="192.168.199.117:20160" \ --data-dir=tikv2 \ --log-file=tikv.log

    ./bin/tikv-server --pd="192.168.199.113:2379,192.168.199.114:2379,192.168.199.115:2379" \ --addr="192.168.199.118:20160" \ --data-dir=tikv3 \ --log-file=tikv.log ```

  3. 在 node1 启动 TiDB

    bash ./bin/tidb-server --store=tikv \ --path="192.168.199.113:2379,192.168.199.114:2379,192.168.199.115:2379" \ --log-file=tidb.log

  4. 使用官方 mysql 客户端连接 TiDB

    bash mysql -h 192.168.199.113 -P 4000 -u root -D test

注意:在生产环境中启动 TiKV 时,建议使用 --config 参数指定配置文件路径,如果不设置这个参数,TiKV 不会读取配置文件。同样,在生产环境中部署 PD 时,也建议使用 --config 参数指定配置文件路径。

注意:如果使用 nohup 在生产环境中启动集群,需要将启动命令放到一个脚本文件里面执行,否则会出现因为 Shell 退出导致 nohup 启动的进程也收到异常信号退出的问题,具体参考进程异常退出

## 功能性测试部署

如果只是对 TiDB 进行测试,并且机器数量有限,我们可以只启动一台 PD 测试 整个集群。

这里我们使用四个节点,部署一个 PD,三个 TiKV,以及一个 TiDB,各个节点以及所运行服务信息如下:

Name Host IP Services
node1 192.168.199.113 PD1, TiDB
node2 192.168.199.114 TiKV1
node3 192.168.199.115 TiKV2
node4 192.168.199.116 TiKV3

请按如下步骤 依次启动 PD 集群,TiKV 集群以及 TiDB:

  1. 在 node1 启动 PD

    bash ./bin/pd-server --name=pd1 \ --data-dir=pd1 \ --client-urls="http://192.168.199.113:2379" \ --peer-urls="http://192.168.199.113:2380" \ --initial-cluster="pd1=http://192.168.199.113:2380" \ --log-file=pd.log

  2. 在 node2,node3,node4 启动 TiKV

    ```bash ./bin/tikv-server --pd="192.168.199.113:2379" \ --addr="192.168.199.114:20160" \ --data-dir=tikv1 \ --log-file=tikv.log

    ./bin/tikv-server --pd="192.168.199.113:2379" \ --addr="192.168.199.115:20160" \ --data-dir=tikv2 \ --log-file=tikv.log

    ./bin/tikv-server --pd="192.168.199.113:2379" \ --addr="192.168.199.116:20160" \ --data-dir=tikv3 \ --log-file=tikv.log ```

  3. 在 node1 启动 TiDB

    bash ./bin/tidb-server --store=tikv \ --path="192.168.199.113:2379" \ --log-file=tidb.log

  4. 使用官方 mysql 客户端连接 TiDB

    bash mysql -h 192.168.199.113 -P 4000 -u root -D test

mysql nosql sql

mysql.ini

mysql的配置文件

[client]
port=3306

[mysql]
default-character-set=utf8

[mysqld]
port=3306
server_id=1
character-set-server=utf8
default-storage-engine=MYISAM
sql-mode="NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
slow_query_log=0
long_query_time=2
local-infile=0
skip-external-locking
#skip-innodb
#log-bin=mysql-bin
#binlog_format=mixed

max_connections=1000
query_cache_size=0
key_buffer_size=64M
sort_buffer_size=256kb
read_buffer_size=512kb
join_buffer_size=2M
read_rnd_buffer_size=2M
max_allowed_packet=16M
table_open_cache=256
tmp_table_size=64M
max_heap_table_size=64M

myisam_max_sort_file_size=64G
myisam_sort_buffer_size=32M
myisam_repair_threads=1

innodb_buffer_pool_size=64M
innodb_log_file_size=16M
innodb_log_buffer_size=2M
innodb_file_per_table=1
innodb_flush_log_at_trx_commit=1
innodb_lock_wait_timeout=50

[mysqldump]
quick
max_allowed_packet=16M

[mysql]
no-auto-rehash

[myisamchk]
key_buffer_size=20M
sort_buffer_size=20M
read_buffer=2M
write_buffer=2M

[mysqlhotcopy]
interactive-timeout

[mysqld_safe]
open-files-limit=8192