轉自：https://my.oschina.net/Kenyon/blog/908370
一、環境
CentOS Linux release 7.3.1611 (Core)
172.26.11.91 pd & tidb
172.26.11.92 tikv
172.26.11.93 tikv
172.26.11.94 tikv
二、安裝
分別在4台服務器上上傳安裝包
wget http://download.pingcap.org/tidb-latest-linux-amd64.tar.gz tar -xzf tidb-latest-linux-amd64.tar.gz cd tidb-latest-linux-amd64 mkdir -p /data/tidb/log ln -s /root/software/tidb/tidb-latest-linux-amd64/bin/pd-tso-bench /usr/bin ln -s /root/software/tidb/tidb-latest-linux-amd64/bin/tikv-server /usr/bin/ ln -s /root/software/tidb/tidb-latest-linux-amd64/bin/tidb-server /usr/bin/ ln -s /root/software/tidb/tidb-latest-linux-amd64/bin/pd-server /usr/bin/ ln -s /root/software/tidb/tidb-latest-linux-amd64/bin/pd-ctl /usr/bin/三、配置使用
1.按照順序啟動
在91上啟動pd服務 pd-server --name=pd1 --多個pd以不同名字命名 --data-dir=/data/tidb/pd --pd路徑 --client-urls="http://172.26.11.91:2379" --peer-urls="http://172.26.11.91:2380" --initial-cluster="pd1=http://172.26.11.91:2380" --多個pd以逗號分隔 --log-file=/data/tidb/log/pd.log & 在92,93,94上啟動tikv tikv-server --pd="172.26.11.91:2379" \ --addr="172.26.11.92:20160" \ --data-dir=/data/tidb/tikv \ --log-file=/data/tidb/log/tikv.log tikv-server --pd="172.26.11.91:2379" \ --addr="172.26.11.93:20160" \ --data-dir=/data/tidb/tikv \ --log-file=/data/tidb/log/tikv.log tikv-server --pd="172.26.11.91:2379" \ --addr="172.26.11.94:20160" \ --data-dir=/data/tidb/tikv \ --log-file=/data/tidb/log/tikv.log & 在91上啟動tipd服務 tidb-server --store=tikv \ --tikv引擎允許分布式存儲，其他如LevelDB等是本地存儲 --path="172.26.11.91:2379" \ --log-file=/data/tidb/log/tidb.log &2.登陸使用
[root@test05 ~]# mysql -h 172.26.11.91 -P 4000 -u root -D test Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 7 Server version: 5.7.1-TiDB-1.0 MySQL Community Server (GPL) Copyright (c) 2000, 2017, Oracle and/or its affiliates. All rights reserved. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql> create database db_kenyon; Query OK, 0 rows affected (2.02 sec) mysql> use db_kenyon; Database changed mysql> create table tbl_kenyon(user_code varchar(64) primary key,user_name varchar(32),ctime timestamp); Query OK, 0 rows affected (2.03 sec) mysql> insert into tbl_kenyon values('01','qiaofeng',now()),('02','murong',now()); Query OK, 2 rows affected (0.01 sec) mysql>三、高可用
tidb的數據都是保存在tikv節點上面，比如上面配置了3套tikv，每套tikv都是獨立的，數據保存的方式和傳統關系型不一樣的是，在tidb里面或者說tikv里面是映射成kv模式存儲的
把92的tikv人為掛掉，此時數據庫的使用會受影響，簡單的一個查詢就會被掛起，直到切換成功
--切換過程
mysql> select * from tbl_kenyon;
+----+-----------+---------------------+
| id | cname | ctime | +----+-----------+---------------------+ | 1 | qiaofeng | 2017-05-23 10:50:43 | | 2 | murong | 2017-05-23 10:50:43 | | 3 | saodiseng | 2017-05-23 10:50:43 | +----+-----------+---------------------+ 3 rows in set (10.24 sec) --切換以后 mysql> select * from tbl_kenyon; +----+-----------+---------------------+ | id | cname | ctime | +----+-----------+---------------------+ | 1 | qiaofeng | 2017-05-23 10:50:43 | | 2 | murong | 2017-05-23 10:50:43 | | 3 | saodiseng | 2017-05-23 10:50:43 | +----+-----------+---------------------+ 3 rows in set (0.00 sec)可以發現經過投票，PD已經連到94上去了（93,92上都能看到），此時讀取表數據很快
2017/05/23 17:59:12.151 server.rs:153: [INFO] TiKV is ready to serve 2017/05/23 17:59:12.517 raft.rs:846: [INFO] [region 2] 3 [term: 1487] received a MsgHeartbeat message with higher term from 7 [term: 1488] 2017/05/23 17:59:12.517 raft.rs:681: [INFO] [region 2] 3 became follower at term 1488 2017/05/23 17:59:12.525 server.rs:460: [INFO] resolve store 6 address ok, addr 172.26.11.94:20160 2017/05/23 17:59:13.517 apply.rs:621: [INFO] [region 2] 3 execute admin command cmd_type: CompactLog compact_log {compact_index: 6437 compact_term: 1488} at [term: 1488, index: 6439] 2017/05/23 17:59:13.644 raftlog_gc.rs:117: [INFO] [region 2] collected 225 log entries 2017/05/23 17:59:43.517 apply.rs:621: [INFO] [region 2] 3 execute admin command cmd_type: CompactLog compact_log {compact_index: 6498 compact_term: 1488} at [term: 1488, index: 6500] 2017/05/23 17:59:43.643 raftlog_gc.rs:117: [INFO] [region 2] collected 61 log entries這是因為92是Region中的leader，假如不是leader的tikv服務器受影響如93,94，數據因為默認做了三個副本（也可以配置5個或者7個副本），服務並不會受影響，但是在日志中會不停地告警
四、水平擴展
其實主要是以上組件模塊的擴展，對於tidb來說，本身是無狀態的，比較容易擴展，pd也可以部署成集群的模式，通過Haproxy、F5或者其他第三方軟件來實現，比較難的Tikv的水平擴展。在每個TiKV的節點里，邏輯上划分了一個或多個store，每個store里又划了一個或多個Region，數據就是存放在Region里面，每個Region的默認值是64M，擴容的過程類似以下細胞分裂的過程，比傳統的RDBMS采用的Sharding方式以及中間件模式要透明很多，也許以后市面上的諸多中間件日子要難過了。
1.添加pd
動態添加pd
pd-server --name=pd2 \
--client-urls="http://172.26.11.95:2379" \ --peer-urls="http://172.26.11.95:2380" \ --join="http://172.26.11.91:2379" --要加入的原pd集群 動態刪除pd pd-ctl -u http://172.26.11.91:2379 >> member delete pd22.添加tikv
添加tikv，比較簡單，直接注冊一個新的tikv，剩下的數據遷移工作就交給pd，以下在91上新注冊一個tikv tikv-server --pd="172.26.11.91:2379" \ --addr="172.26.11.91:20160" \ --data-dir=/data/tidb/tikv \ --log-file=/data/tidb/log/tikv.log & 查看store，新增了一個1001的store，另外也能看出當前的leader在93上面 [root@test05 ~]# pd-ctl -u http://172.26.11.91:2379 » store { "count": 4, "stores": [ { "store": { "id": 6, "address": "172.26.11.94:20160", "state": 0, "state_name": "Up" }, "status": { "store_id": 6, "capacity": "21 GB", "available": "21 GB", "leader_count": 0, "region_count": 1, "sending_snap_count": 0, "receiving_snap_count": 0, "applying_snap_count": 0, "is_busy": false, "start_ts": "2017-05-23T18:05:07+08:00", "last_heartbeat_ts": "2017-05-24T17:52:03.842239159+08:00", "uptime": "23h46m56.842239159s" } }, { "store": { "id": 1001, "address": "172.26.11.91:20160", "state": 0, "state_name": "Up" }, "status": { "store_id": 1001, "capacity": "21 GB", "available": "15 GB", "leader_count": 0, "region_count": 0, "sending_snap_count": 0, "receiving_snap_count": 0, "applying_snap_count": 0, "is_busy": false, "start_ts": "2017-05-24T17:50:12+08:00", "last_heartbeat_ts": "2017-05-24T17:52:03.290658649+08:00", "uptime": "1m51.290658649s" } }, { "store": { "id": 1, "address": "172.26.11.92:20160", "state": 0, "state_name": "Up" }, "status": { "store_id": 1, "capacity": "21 GB", "available": "21 GB", "leader_count": 0, "region_count": 1, "sending_snap_count": 0, "receiving_snap_count": 0, "applying_snap_count": 0, "is_busy": false, "start_ts": "2017-05-23T17:59:12+08:00", "last_heartbeat_ts": "2017-05-24T17:52:06.843194072+08:00", "uptime": "23h52m54.843194072s" } }, { "store": { "id": 4, "address": "172.26.11.93:20160", "state": 0, "state_name": "Up" }, "status": { "store_id": 4, "capacity": "21 GB", "available": "21 GB", "leader_count": 1, "region_count": 1, "sending_snap_count": 0, "receiving_snap_count": 0, "applying_snap_count": 0, "is_busy": false, "start_ts": "2017-05-23T17:22:48+08:00", "last_heartbeat_ts": "2017-05-24T17:52:09.766282426+08:00", "uptime": "24h29m21.766282426s" } } ] }3.刪除tikv
查看1001的store狀態是0，也就是up » store 1001 { "store": { "id": 1001, "address": "172.26.11.91:20160", "state": 0, "state_name": "Up" }, "status": { "store_id": 1001, "capacity": "21 GB", "available": "15 GB", "leader_count": 0, "region_count": 0, "sending_snap_count": 0, "receiving_snap_count": 0, "applying_snap_count": 0, "is_busy": false, "start_ts": "2017-05-24T17:50:12+08:00", "last_heartbeat_ts": "2017-05-24T17:58:57.490156968+08:00", "uptime": "8m45.490156968s" } } --刪除過程，state=1表示正在下線 » store delete 1001 Success! » store 1001 { "store": { "id": 1001, "address": "172.26.11.91:20160", "state": 1, "state_name": "Offline" }, "status": { "store_id": 1001, "capacity": "21 GB", "available": "15 GB", "leader_count": 0, "region_count": 0, "sending_snap_count": 0, "receiving_snap_count": 0, "applying_snap_count": 0, "is_busy": false, "start_ts": "2017-05-24T17:50:12+08:00", "last_heartbeat_ts": "2017-05-24T17:59:17.690136502+08:00", "uptime": "9m5.690136502s" } } --state=2表示數據已經清理，可以關閉 » store 1001 { "store": { "id": 1001, "address": "172.26.11.91:20160", "state": 2, "state_name": "Tombstone" }, "status": { "store_id": 0, "capacity": "0 B", "available": "0 B", "leader_count": 0, "region_count": 0, "sending_snap_count": 0, "receiving_snap_count": 0, "applying_snap_count": 0, "is_busy": false, "start_ts": "1970-01-01T08:00:00+08:00", "last_heartbeat_ts": "0001-01-01T00:00:00Z", "uptime": "0s" } } » 五、總結：
1.維護相對很簡單，官方文檔是有中英文版本，資料更新相對及時，但是實際使用者提供的資料較少
2.Scale Out相比較傳統的RDBMS方案上來看簡化很多，特別是可以摒棄五花八門的中間件
3.從架構上來看，小數據量的性能應該一般，不建議使用，大數據量理論上會較好
4.期待GA版本