Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.
Original topic: tidb_isolation_read_engines修改为[“tiflash”,“tidb”]后，DM同步报错
【TiDB Usage Environment】Test environment
【TiDB Version】6.1.1
【Problem Encountered】After modifying tidb_isolation_read_engines to [“tiflash”, “tidb”], DM synchronization reports an error: valid values can be ‘tikv’
【Reproduction Path】What operations were performed to cause the issue
Modified the instance-level Engine isolation to [“tiflash”, “tidb”]
【Problem Phenomenon and Impact】DM synchronization reports an error: no access path for table ‘gdsc_onlineddl’ is found with ‘tidb_isolation_read_engines’=‘tiflash,tidb’, valid values can be ‘tikv’
【Attachments】
How should this be modified?
It should be changed to [“tiflash”, “tikv”], not “tidb”…
Isolation-read
Configuration Item: isolation-read
- Default value:
["tikv"]
- This configuration item is used to specify the type of storage engine that TiDB reads data from. The optional values are
tikv, tiflash, and tidb. The default value is ["tikv"], which means that TiDB reads data from TiKV by default.
- This configuration item can be dynamically modified using the
SET statement. For example, SET SESSION tidb_isolation_read_engines='tikv,tiflash' means that TiDB reads data from both TiKV and TiFlash in the current session.
I want to use TiFlash entirely for faster query speeds and avoid using TiKV. If I include “tikv,” some SQL queries will go through TiKV.
It depends on the type of query. Not all queries are faster with TiFlash. For example, using TiKV is faster for queries that retrieve a few rows through an index lookup.
What I understand is that whether to use TiKV or TiFlash is determined by the SQL and its execution plan, which calculates the cost.
If the number of your SQL queries is manageable, you can execute all of them to see whether they use TiFlash or TiKV. Based on the actual execution efficiency, you can then perform engine isolation operations.
TiDB’s choice may not always be accurate, so some manual intervention is still necessary.
Most of our operations are custom aggregation for BI reports, and overall TiFlash is faster. So I wanted all SQL queries to go through TiFlash. After changing the parameter configuration, the SQL queries worked fine with no issues, and the performance was better than the optimizer’s automatic selection. Then DM synchronization reported an error: 
saying it couldn’t find TiKV.
Finally, the issue of forced MPP was resolved through other means.
SELECT @@tidb_partition_prune_mode;
- Dynamic Pruning Mode
TiDB has two modes for accessing partitioned tables: dynamic and static. Currently, the default is static mode. If you want to enable dynamic mode, you need to manually set tidb_partition_prune_mode to dynamic.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
|
username: TiDBer_7Oi7Om69
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: