pepezzzz
pepezzzz
V8
2020-05-24 加入
获赞
14
回答
18
文章
15
    把 raft 选举和改为在 PD 上的 etcd 选主,各有优势。pd 选主就和 ticdc 一样,高可用架构简单,对成员数量没有要求。raft 选举最小成员要求3个,优势就是和 pd 解耦可以独立。 权限和多机房的场景都很有现实意义。权重是 LB 的标配功能。用户有多机房的场景,可能需要多 VIP,类似 ticdc 的 cluster-id 功能,及 tidb server label 的位置“感知”,进而和 tikv server label 的 closest-replica 配置就实现流量在机房内自包含。
    4 天前
    TiProxy 管理 VIP 能力是线下部署比较期望的一种能力。 不过集成 keepalived 是不是不太好的一个选择,vrrp 协议是不是太重了,新一代的 MySQL 集群管理软件都不太使用 keepalived。用 raft leader 实现一个 VIP 管理能力是不是更好?
    10 天前
    #!/bin/bash 执行查询语句,并将结果存储到数组中 result=($(mysql -h tidb-ip -P 4000 -u root -p’’ -N -e “select TIDB_TABLE_ID from information_schema.tables where TABLE_SCHEMA=‘your_schema’”)) 遍历数组 for item in “${result[@]}” do AUTO_ID_CACHE=$(curl -s http://tidb-ip:status-port/schema?table_id=${item} 2>/dev/null…
    2 个月前
    https://docs.pingcap.com/zh/tidb-in-kubernetes/stable/backup-to-pv-using-br 文档中描述得很清楚,tikv pod 也需要有 NFS 的 volumemounts 。 确认可以从 Kubernetes 集群中访问用于存储备份数据的 NFS 服务器,并且你已经配置了 TiKV 挂载跟备份任务相同的 NFS 共享目录到相同的本地目录。
    5 个月前
    K8S 环境建议使用 BACKUP CRD 的方式进行备份。
    5 个月前
    不支持自增跳变。需要改 Auto cache id。 update 带有两次列运算时行为不一致。UPDATE h SET h.lock_qty = h.lock_qty + 3, h.usedable_qty=h.onhand_qty - h.lock_qty // 在mysql中用的是上面h.lock_qty = h.lock_qty + 3后的值, 而在tidb中用的更新前的值 提示的 collation 不支持,比如 mysql 8 默认的 collation utf8mb4_0900_ai_ci。
    7 个月前
    除了一个会话内相同操作多次,基本上 conn id + job id 可以定位分段的唯一执行。 BTW: K8S 环境的 POD 日志,最好用其他手段持久化一下。
    1 年前
    还有看一下,tidb.log 在 duplicate key 报错期间的上下日志。
    1 年前
    日志不太全,还是得看一下两个 batch 语句 start a Non-transactional DML做为起始时间 ,最后一个 jobid 做为结束时间 。 admin show ddl jobs 的 truncate 时间 ,看一下各个时间 有没有交叉。
    1 年前
    应该还是遗留数据的问题,从切分上看,没问题。batch.txt 这个子任务前后有没有别的错误。因为执行多次,可以检查一下,truncate 前是不是上一个任务是不是确认结束了。 [2023/02/23 11:57:16.391 +08:00] [INFO] [nontransactional.go:423] [“start a Non-transactional DML”] [conn=4581018440105527369] [job=“job id: 17031, estimated size: 5000, sql: INSERT INTO sbtest.sbtestbak SELECT…
    1 年前
    能不能看一下 tidb.log ,关键字 nontransactional.go 类似这样的日志,有没有出现边界重复。 tidb.log 日志例举如下: [2022/12/30 09:45:53.436 +08:00] [INFO] [nontransactional.go:423] [“start a Non-transactional DML”] [conn=3074535777447707195] [job=“job id: 1, estimated size: 1000, sql: INSERT INTO `test_order`.`test_order_target` SELEC…
    1 年前
    看一下 {clustername}-tidb → query detail → Panic And Critial Error 监控期间的曲线,是否如下图有 critical 的上升? [binlog]
    2 年前
    需要从新的 binlog 位点重新初始化。 下游清理数据后,用 start-task --remove-meta ./task.yaml 重新发起。
    2 年前
    DB2 上就是一个只读操作, create view 不就行了。
    2 年前
    SQL>show config where type=‘tidb’ and name like ‘%ignore%’; binlog.ignore-error是否为 true。 tidb 的日志内是否有 write binlog fail but error ignored 关键字,可能是消息过限导致的。 如果以上符合,参考 https://github.com/pingcap/tidb/blob/master/docs/tidb_http_api.md 的 “Resume the binlog writing when Pump is recovered.” 的一节描述。
    2 年前
    建议直接引用 https://docs.pingcap.com/zh/tidb/v5.0/haproxy-best-practices#配置-haproxy 的配置文件,改后端 IP ,重启 haproxy 后生效。尤其是以下两个参数: timeout client 30000s # 客户端与 HAProxy 连接后,数据传输完毕,即非活动连接的超时时间。 timeout server 30000s # 服务器端非活动连接的超时时间。 如果是 sqlyog 或者是 navicat 工具操作,会有一些自动重…
    2 年前
    chunk-size = 1000 调大,调整到 20万~ 50万,再试一下。
    3 年前
    PRIMARY KEY ( c_w_id , c_d_id , c_id ) 组合主键现在的分段方式,导致 tidb 执行计划需要用全表扫描。 如果要提升速度,可以把 chunk-size = 1000 调大,mysql 会变慢,tidb 因为函数可下推速度较快,大概调整到 20万~ 50万,处于 mysql 和 tidb 两者的平衡点,整体速度会提升。
    3 年前