- Docs Home
- About TiDB
- Quick Start
- Develop
- Overview
- Quick Start
- Build a TiDB Cluster in TiDB Cloud (Developer Tier)
- CRUD SQL in TiDB
- Build a Simple CRUD App with TiDB
- Example Applications
- Connect to TiDB
- Design Database Schema
- Write Data
- Read Data
- Transaction
- Optimize
- Troubleshoot
- Reference
- Cloud Native Development Environment
- Third-party Support
- Deploy
- Software and Hardware Requirements
- Environment Configuration Checklist
- Plan Cluster Topology
- Install and Start
- Verify Cluster Status
- Test Cluster Performance
- Migrate
- Overview
- Migration Tools
- Migration Scenarios
- Migrate from Aurora
- Migrate MySQL of Small Datasets
- Migrate MySQL of Large Datasets
- Migrate and Merge MySQL Shards of Small Datasets
- Migrate and Merge MySQL Shards of Large Datasets
- Migrate from CSV Files
- Migrate from SQL Files
- Migrate from One TiDB Cluster to Another TiDB Cluster
- Migrate from TiDB to MySQL-compatible Databases
- Advanced Migration
- Integrate
- Maintain
- Monitor and Alert
- Troubleshoot
- TiDB Troubleshooting Map
- Identify Slow Queries
- Analyze Slow Queries
- SQL Diagnostics
- Identify Expensive Queries Using Top SQL
- Identify Expensive Queries Using Logs
- Statement Summary Tables
- Troubleshoot Hotspot Issues
- Troubleshoot Increased Read and Write Latency
- Save and Restore the On-Site Information of a Cluster
- Troubleshoot Cluster Setup
- Troubleshoot High Disk I/O Usage
- Troubleshoot Lock Conflicts
- Troubleshoot TiFlash
- Troubleshoot Write Conflicts in Optimistic Transactions
- Troubleshoot Inconsistency Between Data and Indexes
- Performance Tuning
- Tuning Guide
- Configuration Tuning
- System Tuning
- Software Tuning
- SQL Tuning
- Overview
- Understanding the Query Execution Plan
- SQL Optimization Process
- Overview
- Logic Optimization
- Physical Optimization
- Prepare Execution Plan Cache
- Control Execution Plans
- Tutorials
- TiDB Tools
- Overview
- Use Cases
- Download
- TiUP
- Documentation Map
- Overview
- Terminology and Concepts
- Manage TiUP Components
- FAQ
- Troubleshooting Guide
- Command Reference
- Overview
- TiUP Commands
- TiUP Cluster Commands
- Overview
- tiup cluster audit
- tiup cluster check
- tiup cluster clean
- tiup cluster deploy
- tiup cluster destroy
- tiup cluster disable
- tiup cluster display
- tiup cluster edit-config
- tiup cluster enable
- tiup cluster help
- tiup cluster import
- tiup cluster list
- tiup cluster patch
- tiup cluster prune
- tiup cluster reload
- tiup cluster rename
- tiup cluster replay
- tiup cluster restart
- tiup cluster scale-in
- tiup cluster scale-out
- tiup cluster start
- tiup cluster stop
- tiup cluster template
- tiup cluster upgrade
- TiUP DM Commands
- Overview
- tiup dm audit
- tiup dm deploy
- tiup dm destroy
- tiup dm disable
- tiup dm display
- tiup dm edit-config
- tiup dm enable
- tiup dm help
- tiup dm import
- tiup dm list
- tiup dm patch
- tiup dm prune
- tiup dm reload
- tiup dm replay
- tiup dm restart
- tiup dm scale-in
- tiup dm scale-out
- tiup dm start
- tiup dm stop
- tiup dm template
- tiup dm upgrade
- TiDB Cluster Topology Reference
- DM Cluster Topology Reference
- Mirror Reference Guide
- TiUP Components
- PingCAP Clinic Diagnostic Service
- TiDB Operator
- Dumpling
- TiDB Lightning
- TiDB Data Migration
- About TiDB Data Migration
- Architecture
- Quick Start
- Deploy a DM cluster
- Tutorials
- Advanced Tutorials
- Maintain
- Cluster Upgrade
- Tools
- Performance Tuning
- Manage Data Sources
- Manage Tasks
- Export and Import Data Sources and Task Configurations of Clusters
- Handle Alerts
- Daily Check
- Reference
- Architecture
- Command Line
- Configuration Files
- OpenAPI
- Compatibility Catalog
- Secure
- Monitoring and Alerts
- Error Codes
- Glossary
- Example
- Troubleshoot
- Release Notes
- Backup & Restore (BR)
- TiDB Binlog
- TiCDC
- Dumpling
- sync-diff-inspector
- TiSpark
- Reference
- Cluster Architecture
- Key Monitoring Metrics
- Secure
- Privileges
- SQL
- SQL Language Structure and Syntax
- SQL Statements
ADD COLUMNADD INDEXADMINADMIN CANCEL DDLADMIN CHECKSUM TABLEADMIN CHECK [TABLE|INDEX]ADMIN SHOW DDL [JOBS|QUERIES]ADMIN SHOW TELEMETRYALTER DATABASEALTER INDEXALTER INSTANCEALTER PLACEMENT POLICYALTER TABLEALTER TABLE COMPACTALTER USERANALYZE TABLEBACKUPBATCHBEGINCHANGE COLUMNCOMMITCHANGE DRAINERCHANGE PUMPCREATE [GLOBAL|SESSION] BINDINGCREATE DATABASECREATE INDEXCREATE PLACEMENT POLICYCREATE ROLECREATE SEQUENCECREATE TABLE LIKECREATE TABLECREATE USERCREATE VIEWDEALLOCATEDELETEDESCDESCRIBEDODROP [GLOBAL|SESSION] BINDINGDROP COLUMNDROP DATABASEDROP INDEXDROP PLACEMENT POLICYDROP ROLEDROP SEQUENCEDROP STATSDROP TABLEDROP USERDROP VIEWEXECUTEEXPLAIN ANALYZEEXPLAINFLASHBACK TABLEFLUSH PRIVILEGESFLUSH STATUSFLUSH TABLESGRANT <privileges>GRANT <role>INSERTKILL [TIDB]LOAD DATALOAD STATSMODIFY COLUMNPREPARERECOVER TABLERENAME INDEXRENAME TABLEREPLACERESTOREREVOKE <privileges>REVOKE <role>ROLLBACKSELECTSET DEFAULT ROLESET [NAMES|CHARACTER SET]SET PASSWORDSET ROLESET TRANSACTIONSET [GLOBAL|SESSION] <variable>SHOW ANALYZE STATUSSHOW [BACKUPS|RESTORES]SHOW [GLOBAL|SESSION] BINDINGSSHOW BUILTINSSHOW CHARACTER SETSHOW COLLATIONSHOW [FULL] COLUMNS FROMSHOW CONFIGSHOW CREATE PLACEMENT POLICYSHOW CREATE SEQUENCESHOW CREATE TABLESHOW CREATE USERSHOW DATABASESSHOW DRAINER STATUSSHOW ENGINESSHOW ERRORSSHOW [FULL] FIELDS FROMSHOW GRANTSSHOW INDEX [FROM|IN]SHOW INDEXES [FROM|IN]SHOW KEYS [FROM|IN]SHOW MASTER STATUSSHOW PLACEMENTSHOW PLACEMENT FORSHOW PLACEMENT LABELSSHOW PLUGINSSHOW PRIVILEGESSHOW [FULL] PROCESSSLISTSHOW PROFILESSHOW PUMP STATUSSHOW SCHEMASSHOW STATS_HEALTHYSHOW STATS_HISTOGRAMSSHOW STATS_METASHOW STATUSSHOW TABLE NEXT_ROW_IDSHOW TABLE REGIONSSHOW TABLE STATUSSHOW [FULL] TABLESSHOW [GLOBAL|SESSION] VARIABLESSHOW WARNINGSSHUTDOWNSPLIT REGIONSTART TRANSACTIONTABLETRACETRUNCATEUPDATEUSEWITH
- Data Types
- Functions and Operators
- Overview
- Type Conversion in Expression Evaluation
- Operators
- Control Flow Functions
- String Functions
- Numeric Functions and Operators
- Date and Time Functions
- Bit Functions and Operators
- Cast Functions and Operators
- Encryption and Compression Functions
- Locking Functions
- Information Functions
- JSON Functions
- Aggregate (GROUP BY) Functions
- Window Functions
- Miscellaneous Functions
- Precision Math
- Set Operations
- List of Expressions for Pushdown
- TiDB Specific Functions
- Clustered Indexes
- Constraints
- Generated Columns
- SQL Mode
- Table Attributes
- Transactions
- Garbage Collection (GC)
- Views
- Partitioning
- Temporary Tables
- Cached Tables
- Character Set and Collation
- Placement Rules in SQL
- System Tables
mysql- INFORMATION_SCHEMA
- Overview
ANALYZE_STATUSCLIENT_ERRORS_SUMMARY_BY_HOSTCLIENT_ERRORS_SUMMARY_BY_USERCLIENT_ERRORS_SUMMARY_GLOBALCHARACTER_SETSCLUSTER_CONFIGCLUSTER_HARDWARECLUSTER_INFOCLUSTER_LOADCLUSTER_LOGCLUSTER_SYSTEMINFOCOLLATIONSCOLLATION_CHARACTER_SET_APPLICABILITYCOLUMNSDATA_LOCK_WAITSDDL_JOBSDEADLOCKSENGINESINSPECTION_RESULTINSPECTION_RULESINSPECTION_SUMMARYKEY_COLUMN_USAGEMETRICS_SUMMARYMETRICS_TABLESPARTITIONSPLACEMENT_POLICIESPROCESSLISTREFERENTIAL_CONSTRAINTSSCHEMATASEQUENCESSESSION_VARIABLESSLOW_QUERYSTATISTICSTABLESTABLE_CONSTRAINTSTABLE_STORAGE_STATSTIDB_HOT_REGIONSTIDB_HOT_REGIONS_HISTORYTIDB_INDEXESTIDB_SERVERS_INFOTIDB_TRXTIFLASH_REPLICATIKV_REGION_PEERSTIKV_REGION_STATUSTIKV_STORE_STATUSUSER_PRIVILEGESVIEWS
METRICS_SCHEMA
- UI
- TiDB Dashboard
- Overview
- Maintain
- Access
- Overview Page
- Cluster Info Page
- Top SQL Page
- Key Visualizer Page
- Metrics Relation Graph
- SQL Statements Analysis
- Slow Queries Page
- Cluster Diagnostics
- Search Logs Page
- Instance Profiling
- Session Management and Configuration
- FAQ
- CLI
- Command Line Flags
- Configuration File Parameters
- System Variables
- Storage Engines
- Telemetry
- Errors Codes
- Table Filter
- Schedule Replicas by Topology Labels
- FAQs
- Release Notes
- All Releases
- Release Timeline
- TiDB Versioning
- v6.1
- v6.0
- v5.4
- v5.3
- v5.2
- v5.1
- v5.0
- v4.0
- v3.1
- v3.0
- v2.1
- v2.0
- v1.0
- Glossary
TiDB Binlog Configuration File
This document introduces the configuration items of TiDB Binlog.
Pump
This section introduces the configuration items of Pump. For the example of a complete Pump configuration file, see Pump Configuration.
addr
- Specifies the listening address of HTTP API in the format of
host:port. - Default value:
127.0.0.1:8250
advertise-addr
- Specifies the externally accessible HTTP API address. This address is registered in PD in the format of
host:port. - Default value:
127.0.0.1:8250
socket
- The Unix socket address that HTTP API listens to.
- Default value: ""
pd-urls
- Specifies the comma-separated list of PD URLs. If multiple addresses are specified, when the PD client fails to connect to one address, it automatically tries to connect to another address.
- Default value:
http://127.0.0.1:2379
data-dir
- Specifies the directory where binlogs and their indexes are stored locally.
- Default value:
data.pump
heartbeat-interval
- Specifies the heartbeat interval (in seconds) at which the latest status is reported to PD.
- Default value:
2
gen-binlog-interval
- Specifies the interval (in seconds) at which data is written into fake binlog.
- Default value:
3
gc
- Specifies the number of days (integer) that binlogs can be stored locally. Binlogs stored longer than the specified number of days are automatically deleted.
- Default value:
7
log-file
- Specifies the path where log files are stored. If the parameter is set to an empty value, log files are not stored.
- Default value: ""
log-level
- Specifies the log level.
- Default value:
info
node-id
- Specifies the Pump node ID. With this ID, this Pump process can be identified in the cluster.
- Default value:
hostname:port number. For example,node-1:8250.
security
This section introduces configuration items related to security.
ssl-ca
- Specifies the file path of the trusted SSL certificate list or CA list. For example,
/path/to/ca.pem. - Default value: ""
ssl-cert
- Specifies the path of the X509 certificate file encoded in the Privacy Enhanced Mail (PEM) format. For example,
/path/to/pump.pem. - Default value: ""
ssl-key
- Specifies the path of the X509 key file encoded in the PEM format. For example,
/path/to/pump-key.pem. - Default value: ""
storage
This section introduces configuration items related to storage.
sync-log
- Specifies whether to use
fsyncafter each batch write to binlog to ensure data safety. - Default value:
true
kv_chan_cap
- Specifies the number of write requests that the buffer can store before Pump receives these requests.
- Default value:
1048576(that is, 2 to the power of 20)
slow_write_threshold
- The threshold (in seconds). If it takes longer to write a single binlog file than this specified threshold, the write is considered slow write and
"take a long time to write binlog"is output in the log. - Default value:
1
stop-write-at-available-space
- Binlog write requests is no longer accepted when the available storage space is below this specified value. You can use the format such as
900 MB,5 GB, and12 GiBto specify the storage space. If there is more than one Pump node in the cluster, when a Pump node refuses a write request because of the insufficient space, TiDB will automatically write binlogs to other Pump nodes. - Default value:
10 GiB
kv
Currently the storage of Pump is implemented based on GoLevelDB. Under storage there is also a kv subgroup that is used to adjust the GoLevel configuration. The supported configuration items are shown as below:
- block-cache-capacity
- block-restart-interval
- block-size
- compaction-L0-trigger
- compaction-table-size
- compaction-total-size
- compaction-total-size-multiplier
- write-buffer
- write-L0-pause-trigger
- write-L0-slowdown-trigger
For the detailed description of the above items, see GoLevelDB Document.
Drainer
This section introduces the configuration items of Drainer. For the example of a complete Drainer configuration file, see Drainer Configuration
addr
- Specifies the listening address of HTTP API in the format of
host:port. - Default value:
127.0.0.1:8249
advertise-addr
- Specifies the externally accessible HTTP API address. This address is registered in PD in the format of
host:port. - Default value:
127.0.0.1:8249
log-file
- Specifies the path where log files are stored. If the parameter is set to an empty value, log files are not stored.
- Default value: ""
log-level
- Specifies the log level.
- Default value:
info
node-id
- Specifies the Drainer node ID. With this ID, this Drainer process can be identified in the cluster.
- Default value:
hostname:port number. For example,node-1:8249.
data-dir
- Specifies the directory used to store files that need to be saved during Drainer operation.
- Default value:
data.drainer
detect-interval
- Specifies the interval (in seconds) at which PD updates the Pump information.
- Default value:
5
pd-urls
- The comma-separated list of PD URLs. If multiple addresses are specified, the PD client will automatically attempt to connect to another address if an error occurs when connecting to one address.
- Default value:
http://127.0.0.1:2379
initial-commit-ts
- Specifies from which commit timestamp of the transaction the replication process starts. This configuration is applicable only to the Drainer node that is in the replication process for the first time. If a checkpoint already exists in the downstream, the replication will be performed according to the time recorded in the checkpoint.
- commit ts (commit timestamp) is a specific point in time for transaction commits in TiDB. It is a globally unique and increasing timestamp from PD as the unique ID of the current transaction. You can get the
initial-commit-tsconfiguration in the following typical ways:- If BR is used, you can get
initial-commit-tsfrom the backup TS recorded in the metadata backed up by BR (backupmeta). - If Dumpling is used, you can get
initial-commit-tsfrom the Pos recorded in the metadata backed up by Dumpling (metadata), - If PD Control is used,
initial-commit-tsis in the output of thetsocommand.
- If BR is used, you can get
- Default value:
-1. Drainer will get a new timestamp from PD as the starting time, which means that the replication process starts from the current time.
synced-check-time
- You can access the
/statuspath through the HTTP API to query the status of Drainer replication.synced-check-timespecifies how many minutes from the last successful replication is considered assynced, that is, the replication is complete. - Default value:
5
compressor
- Specifies the compression algorithm used for data transfer between Pump and Drainer. Currently only the
gzipalgorithm is supported. - Default value: "", which means no compression.
security
This section introduces configuration items related to security.
ssl-ca
- Specifies the file path of the trusted SSL certificate list or CA list. For example,
/path/to/ca.pem. - Default value: ""
ssl-cert
- Specifies the path of the X509 certificate file encoded in the PEM format. For example,
/path/to/drainer.pem. - Default value: ""
ssl-key
- Specifies the path of the X509 key file encoded in the PEM format. For example,
/path/to/pump-key.pem. - Default value: ""
syncer
The syncer section includes configuration items related to the downstream.
db-type
Currently, the following downstream types are supported:
mysqltidbkafkafile
Default value: mysql
sql-mode
- Specifies the SQL mode when the downstream is the
mysqlortidbtype. If there is more than one mode, use commas to separate them. - Default value: ""
ignore-txn-commit-ts
- Specifies the commit timestamp at which the binlog is ignored, such as
[416815754209656834, 421349811963822081]. - Default value:
[]
ignore-schemas
- Specifies the database to be ignored during replication. If there is more than one database to be ignored, use commas to separate them. If all changes in a binlog file are filtered, the whole binlog file is ignored.
- Default value:
INFORMATION_SCHEMA,PERFORMANCE_SCHEMA,mysql
ignore-table
Ignores the specified table changes during replication. You can specify multiple tables to be ignored in the toml file. For example:
[[syncer.ignore-table]]
db-name = "test"
tbl-name = "log"
[[syncer.ignore-table]]
db-name = "test"
tbl-name = "audit"
If all changes in a binlog file are filtered, the whole binlog file is ignored.
Default value: []
replicate-do-db
- Specifies the database to be replicated. For example,
[db1, db2]. - Default value:
[]
replicate-do-table
Specifies the table to be replicated. For example:
[[syncer.replicate-do-table]]
db-name ="test"
tbl-name = "log"
[[syncer.replicate-do-table]]
db-name ="test"
tbl-name = "~^a.*"
Default value: []
txn-batch
- When the downstream is the
mysqlortidbtype, DML operations are executed in different batches. This parameter specifies how many DML operations can be included in each transaction. - Default value:
20
worker-count
- When the downstream is the
mysqlortidbtype, DML operations are executed concurrently. This parameter specifies the concurrency numbers of DML operations. - Default value:
16
disable-dispatch
- Disables the concurrency and forcibly set
worker-countto1. - Default value:
false
safe-mode
If the safe mode is enabled, Drainer modifies the replication updates in the following way:
Insertis modified toReplace IntoUpdateis modified toDeleteplusReplace Into
Default value: false
syncer.to
The syncer.to section introduces different types of downstream configuration items according to configuration types.
mysql/tidb
The following configuration items are related to connection to downstream databases:
host: If this item is not set, TiDB Binlog tries to check theMYSQL_HOSTenvironment variable which islocalhostby default.port: If this item is not set, TiDB Binlog tries to check theMYSQL_PORTenvironment variable which is3306by default.user: If this item is not set, TiDB Binlog tries to check theMYSQL_USERenvironment variable which isrootby default.password: If this item is not set, TiDB Binlog tries to check theMYSQL_PSWDenvironment variable which is""by default.
file
dir: Specifies the directory where binlog files are stored. If this item is not set,data-diris used.
kafka
When the downstream is Kafka, the valid configuration items are as follows:
zookeeper-addrskafka-addrskafka-versionkafka-max-messageskafka-max-message-sizetopic-name
syncer.to.checkpoint
type: Specifies in what way the replication progress is saved. Currently, the available options aremysql,tidb, andfile.This configuration item is the same as the downstream type by default. For example, when the downstream is
file, the checkpoint progress is saved in the local file<data-dir>/savepoint; when the downstream ismysql, the progress is saved in the downstream database. If you need to explicitly specify usingmysqlortidbto store the progress, make the following configuration:schema:"tidb_binlog"by default.NoteWhen deploying multiple Drainer nodes in the same TiDB cluster, you need to specify a different checkpoint schema for each node. Otherwise, the replication progress of two instances will overwrite each other.
hostuserpasswordport