请问有计划支持跨库做import么,现在先dumpling然后lightning还要落地,不但时间长而且还要很大的磁盘空间。
是的毛老师的文章,但是我之前是在知乎上看到了就直接在知乎上搜索的。
如果同步到下游tidb集群(下游tidb集群当作异地高可用),从数据同步数据安全方面(非同步效率)我感觉有几个点需要注意:
1、关于数据定期比对,建议所有表必须为聚簇索引表,避免sync_diff工具做数据比对时候导致集群抖动,参考:
sync_diff_inspector做上下游数据对比时可能会导致集群性能抖动
2、不使用lighning local模式导入数据避免数据不同步(对于特殊批次表,可以不设置同步,两侧集群分别local模式导数,减少ticdc带宽)
3、ticdc不会做用户、用户权限、密码的同步,需要自己维护。
4、ticdc不会同步sequence对象、视图,需要定期做检…
反半连接只支持hashjoin,猜测左外反半连接支持indexjoin。
可以参考这篇文章中的左外反半连接做下hint走索引的测试:
应该优化器并没有对column is not null情况进行优化。可以顺着这篇文章分析分析代码看是否有一些发现:
试下调整这个呢:tidb_opt_scan_factor。
tidb_opt_seek_factor这个参数看起来是查找一个range的代价,你这里面数据量看起来比较小,可能就一个range。
tidb的并行框架是算子内并行(业界tp数据库较多的是算子间并行),一条语句中多来几个hash join+hashagg 很容易吃到十几个CPU,他这个8c打满也是常见的。
算子间并行:容易在SQL级别控制并行度,比如设置了parallel=3,那么基本最多就是3c,优点是:语句级CPU控制力度较好,缺点是:容易造成局部算力不足,ap能力偏弱一些。
算子内并行:在算子级别控制并行度,一个算子可能吃多个CPU,算子多了起来就容易被严重放大,优点是ap能力较强,纯ap场景下比较占优,缺点是:不容易控制CPU使用量,容易影响tp业务。
大概率是join reorder的问题。
你用explain analyze format='verbose' select xxx from t方式看下执行计划的estCost,我估计优化器也是会显示执行慢(1分钟左右)的那个执行计划的estCost要大,但是优化器还是没有选择成本更低的执行路径,这是因为tidb的join reorder发生在逻辑优化阶段,只会根据结果集的大小来选择哪两张表先做关联,真正的cost计算发生在物理优化阶段,但此时关联顺序已经确定了。
mysql> show variables like '%cost_model%';
+-------------------------+-------+
| Variable_name | Value |
+-------------------------+-------+
| tidb_cost_model_version | 2 |
+-------------------------+-------+
1 row in set (0.00 sec)
在tidb_cost_model_version = 2的情况下可以查看执行计划cost成本代价计算方式…
我们是对于所有数据库都是BR全备。
增量日志备份的选择是:
1、在6.5以下版本采用tidb-binlog做binlog日志备份;
2、在6.5版本优先使用tidb-binlog做日志备份,但会牺牲分区表的exchange功能(drainer不支持该ddl的同步)。如果一定要用分区表的exchange功能则推荐用pitr做增量日志备份,但不能使用快速创建索引(fastreorg)功能、且pitr在目前版本不兼容lightning的local模式导数;
3、在7.5版本优先采用pitr方式做增量日志备份,该版本可以快速创建索引但注意还是和lightning local模式不兼容。
官方…
以前感觉tiproxy有点鸡肋,没什么用, 听大佬解答后茅塞顿开
如果涉及key的更新(聚簇索引表的主键或非聚簇索引表的rowid)则是获取整行记录先delete(insert标记)再insert。如果不涉及key的更新则直接insert。
其实我们更常用的涉及大批量数据操作的是delete,但是delete也是需要把整行数据都读取到tidb-server中,主要是因为需要同步tidb-binlog和对索引字段的维护,其实这块我感觉是可以优化的只是代价较大。
看这个issue对应的PR只合并到了主干版本,7.1应该是不能通过打补丁升级解决的。需要升级大版本。
如果短期不能升级大版本,先尝试其它方式绕过下吧。