黄东旭解析 TiDB 的核心优势
1047
2023-04-03
分布式数据库TiDB的部署
一、环境
CentOS Linux release 7.3.1611 (Core)172.26.11.91 pd & tidb172.26.11.92 tikv172.26.11.93 tikv172.26.11.94 tikv
二、安装
分别在4台服务器上上传安装包
三、配置使用
1.按照顺序启动
2.登陆使用
[root@test05 ~]# mysql -h 172.26.11.91 -P 4000 -u root -D testWelcome to the MySQL monitor. Commands end with ; or \g.Your MySQL connection id is 7Server version: 5.7.1-TiDB-1.0 MySQL Community Server (GPL)Copyright (c) 2000, 2017, *** and/or its affiliates. All rights reserved.*** is a registered trademark of *** Corporation and/or itsaffiliates. Other names may be trademarks of their respectiveowners.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 changedmysql> 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 serve2017/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 14882017/05/23 17:59:12.525 server.rs:460: [INFO] resolve store 6 address ok, addr 172.26.11.94:201602017/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 entries2017/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
2.添加tikv
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 1001Success!» 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版本
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。