Day21
Tidb集群的混合部署方案
机架感知
什么是机架感知
程序知晓自己所在位置 就是机架感知
为什么要机架感知
TiDB是一个分布式数据库。为了保证高可用性，采用了多副本和多数提交策略，保证了集群不受破坏。
为了在发生最大范围的故障(如数据中心故障)时实现高可用性，需要对机架进行感知。它有助于使副本分布更加分散。
如何配置机架感知
在TiDB中实现机架感知
pd-server设置replication.location_label = [“dc”，“zone”，“rack”，“host”]， dc高于zone。用户可以自行重命名级别名称。
向所有tikv实例添加标签信息，例如lable=[dc]=“beijing”，zone=“zone1”，rack=“rack1”，host="192.168.0.1
对于regions，pd-server可以根据tikv实例的标签信息计算出所有tikv实例的得分。
默认情况下，集群中有3个副本，分别为peer1、peer2和peer3。我们假设peer1在任何一个tikv实例上，我们可以计算它对其他两个实例的权重作为分数。
score=100**(len(location-labels)-(diff(peer1.peer2))-100**(len(locatiom-labels)-(diff(peer1.peer3))
注释:len(location-labels)表示级别总数diff(peer1,peer2)是peer1和peer2之间第一个不同的等级号，当两个对等体在同一个tikv上时，这部分分数直接为0
根据分数，pd-server将使用最高的tikv实例作为peer1的存储
(dc1 host1) (dc1,host2)(dc2,host3,dc2,host4)(dc3,host5)(dc3,host6)
Tidb 跨数据中心部署方案
首先，在我们操作之前，我们需要知道哪些极端情况下可能会丢失一些数据
一些地区的所有副本都在灾难中丢失了
一些地区超过一半的副本在灾难中丢失了，剩下的副本没有收到最近的写入
什么情况下容易出现这些问题
在停电期间没有设置同步日志参数
没有正确的标签设置
有东西需要记录
集群版本,同步日志配置,异常宕机TikV次数
有超过一半的tikv副本在故障节点上的region，记录ID
无法启动的TiKV个数及其日志
需要传达给用户的内容
在存在数据丢失风险的情况下，询问你是否可以容忍
最近写的部分丢失
丢失部分区域的所有数据
你能重定向一些丢失的数据吗
开始恢复操作
为了减少恢复期间可能出现的异常，我们建议调优PD配置并临时禁用相关的调度
输入pd-ctl，执行如下命令:
Config set region-schedule-limit 0
Config set replica-schedule-limit 0
Config set leader-schedule-limit 0
Config set merge-schedule-limit 0
使用PD-CTL检查超过一半以上副本在故障节点上的region，并记录它们的id
方法1:
要求:对停电的TikV执行;关闭的TiKV
tikv-ctl --db/path/to/tikv-data/db bad-regions
2。要求:PD处于运行状态(假设故障节点为1,4,5)
$pd-ctl-u -d region --jq=’.regions[]|{id:.id, peer_stores: [.peers[].store_id]|select(length as $total | map(if.=(1,4,5) then .else empty end) I length>=$ total -length)}’
将上面找到的region设置为tombstone状态
要求: TikV节点失败;TiKV关闭
$TikV -ctl --db /path/to/ TikV-data/db tombstone -r --force
在剩余的正常节点上，移除故障节点上的peers
根据这些region的数量，可以采取不同的解决方案:
4.1。如果这些region的数量很少，则可以从给定区域的剩余副本中删除故障节点上的所有peers
$tikv-ctl–db /path/to/tikv-data/db unsafe-recover remove-fail-stores -s <s1,s2> -r <r1,r2,r3>
4.2。相反，位于故障节点上的所有peers可以从所有实例的所有区域中移除，而所有实例中没有发生掉电
$tikv-ctl–db /path/to/tikv-data/db unsafe-recover remove-fail-stores -s <s1,s2> -all-regions .
在这一点上，理论上，所有仍然有副本的区域都可以选举leader，尽管，正如我们分析的那样，他们可能会丢失一些最近的更新。此时，我们可以重启PD，重启TiKV集群，对所有副本缺失的region进行处理，如下:
使用pd-ctl检查没有Leader的区域
需求:PD正在运行
$pd-ctl-u -d region --jq’.regions[]Iselect(has(“leader”)]Inot)|{id:…id, peer_stores:[.peersc[].store_id]}’
创建一个空region以解决不可用错误
$ tikv-ctl-db/path/to/tikv-data/db recreate-region-pd -r sregion_id>
根据Region ID要求确认Region属于哪个表或索引
需求:PD、TiKV、TIDB正在运行
$curl http://{TiDBIP}:10080/regions/{regionID}
- 在实践中，通常更有效的做法是在断电前一段时间内直接询问用户他们已经写入了哪些表，是否存在DDL操作，以及是否可以重新使用更多的上游数据来重新写入
8.1。对于索引:检查数据索引一致性
select count(*) from table
select count(*) from table force index ‘idx_name’
8.2。对于记录:重新导入数据的这一部分
- 恢复PD调度参数
»config set region-schedule-limit xx
»config set replica-schedule-limit xx
»config set leader-schedule-limit xx
»config set merge-schedule-limit xx