diff --git a/.github/workflows/ci.yaml b/.github/workflows/ci.yaml deleted file mode 100644 index 1bee97b00b18..000000000000 --- a/.github/workflows/ci.yaml +++ /dev/null @@ -1,23 +0,0 @@ -name: ci - -on: [pull_request] - -concurrency: - group: ${{ github.workflow }}-${{ github.ref }}-${{ github.event_name }} - cancel-in-progress: true - -jobs: - pull: - runs-on: ubuntu-latest - steps: - - name: Check out - uses: actions/checkout@v4 - - uses: actions/setup-node@v4 - with: - node-version: "16" - - name: Verify duplicated file names - run: ./scripts/verify-duplicated-file-name.sh - - name: Verify internal links - run: ./scripts/verify-links.sh - - name: Verify internal link anchors - run: ./scripts/verify-link-anchors.sh diff --git a/.github/workflows/link-fail-fast.yaml b/.github/workflows/link-fail-fast.yaml deleted file mode 100644 index 9f3466d0c899..000000000000 --- a/.github/workflows/link-fail-fast.yaml +++ /dev/null @@ -1,27 +0,0 @@ -name: Links (Fail Fast) - -on: - pull_request: - -jobs: - linkChecker: - runs-on: ubuntu-latest - steps: - - uses: actions/checkout@v4 - with: - fetch-depth: 2 - - - name: 'Get a list of changed markdown files to process' - id: changed-files - run: | - CHANGED_FILES=$(git diff-tree --name-only --diff-filter 'AM' -r HEAD^1 HEAD -- "*.md" | sed -z "s/\n$//;s/\n/' '/g") - echo "all_changed_files=${CHANGED_FILES}" >> $GITHUB_OUTPUT - - - name: Link Checker - if: ${{ steps.changed-files.outputs.all_changed_files }} - uses: lycheeverse/lychee-action@v2.3.0 - with: - fail: true - args: --root-dir $(pwd) -E -i -n -t 45 -- '${{ steps.changed-files.outputs.all_changed_files }}' - env: - GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}} diff --git a/.github/workflows/link.yaml b/.github/workflows/link.yaml deleted file mode 100644 index 6b3be2a3489e..000000000000 --- a/.github/workflows/link.yaml +++ /dev/null @@ -1,35 +0,0 @@ -name: Links - -on: - repository_dispatch: - workflow_dispatch: - schedule: - - cron: "0 0 * * 1" - -jobs: - linkChecker: - runs-on: ubuntu-latest - steps: - - uses: actions/checkout@v4 - - - name: Download Exclude Path - run: | - curl https://raw.githubusercontent.com/pingcap/docs/master/.lycheeignore --output .lycheeignore - - - name: Check Links - uses: lycheeverse/lychee-action@v1.6.1 - with: - # For parameter description, see https://github.com/lycheeverse/lychee#commandline-parameters - args: -E --exclude-mail -v -i -n -t 45 -- **/*.md *.md - output: out.md - env: - GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}} - - - name: Create Issue From File - uses: peter-evans/create-issue-from-file@v4 - with: - title: Broken Link Detected - content-filepath: out.md - -# - name: Fail if there were link errors -# run: exit ${{ steps.lychee.outputs.exit_code }} diff --git a/.github/workflows/prevent-deletion.yaml b/.github/workflows/prevent-deletion.yaml deleted file mode 100644 index 8e4a9994fa0f..000000000000 --- a/.github/workflows/prevent-deletion.yaml +++ /dev/null @@ -1,46 +0,0 @@ -name: Prevent Deletion - -on: - pull_request_target: - types: [opened, reopened, synchronize] - -concurrency: - group: ${{ github.workflow }}-${{ github.ref }}-${{ github.event_name }} - cancel-in-progress: true - -jobs: - check: - permissions: - checks: write - runs-on: ubuntu-latest - steps: - - name: Checkout base - uses: actions/checkout@v4 - - name: Fetch head - run: | - git remote add head ${{ github.event.pull_request.head.repo.clone_url }} - git fetch --depth=1 head ${{ github.event.pull_request.head.ref }} - - name: Find changes - run: | - git rev-parse '${{ github.event.pull_request.head.sha }}' - if git diff --merge-base --name-only --diff-filter 'D' HEAD '${{ github.event.pull_request.head.sha }}' | grep -E '^media/.*\.(jpg|png|jpeg|gif)$' >/tmp/changed_files; then - cat /tmp/changed_files - echo '{"name":"Image Deletion Check","head_sha":"${{ github.event.pull_request.head.sha }}","status":"completed","conclusion":"failure"}' > /tmp/body.json - jq \ - --arg count "$(wc -l /tmp/changed_files | awk '{print $1}')" \ - --arg summary "$(cat /tmp/changed_files | sed 's/^/- /')" \ - '.output.title = "Found " + $count + " deleted images" | .output.summary = $summary' \ - /tmp/body.json > /tmp/body2.json - else - echo '{"name":"Image Deletion Check","head_sha":"${{ github.event.pull_request.head.sha }}","status":"completed","conclusion":"success","output":{"title":"OK","summary":"No deleted images"}}' > /tmp/body2.json - fi - - name: Publish result - run: | - cat /tmp/body2.json - curl \ - -sSL \ - -X POST \ - -H "Accept: application/vnd.github+json" \ - -H "Authorization: token ${{ github.token }}" \ - -T '/tmp/body2.json' \ - 'https://api.github.com/repos/${{ github.repository }}/check-runs' diff --git a/faq/ddl-faq-test3.md b/faq/ddl-faq-test3.md new file mode 100644 index 000000000000..90c730214bfc --- /dev/null +++ b/faq/ddl-faq-test3.md @@ -0,0 +1,67 @@ +--- +title: DDL 常见问题 +summary: 介绍 DDL 相关的常见问题。 +--- + +# DDL 常见问题 + +本文档介绍 TiDB 中常见的些 DDL 问题。 + +## TiDB DDL 是否支持 DDL 语句间并行？具体的一些运行特征是怎样地？ + +在 TiDB v6.2 之后，TiDB 提供并发 DDL（concurrent DDL） 执行的能力。 并发 DDL 主要是提供 DDL 语句间的并发执行支持。这里和以前的 DDL 执行将会发生如下变化： + +1. 需要判断 DDL 语句间是否有相关性，如果有相关性的 DDL 语句将会按照进入 TiDB 的顺序执行，没有相关性的 DDL 语句可以并发执行。并发判断规则： + 1. 相同表上的 DDL 语句之间具有相关性，需要按照进入 TiDB 的顺序执行； + 2. 对于 Schema 上的操作，可能会对于 schema 中的表上的 DDL 语句建立相关性，目前 Drop Schema 会对于其包含 Schema 上的 DDL 产生相关性；也需要顺序执行； +2. 是否所有的 DDL 语句都会并发执行？ + 当前，答案是否定的，在 TiDB 中 DDL 语句被分为两类， + 1. 普通（general）DDL 语句，这类 DDL 语句的执行只需要修改对象的元数据，不需要操作 schema 存储的数据，通常在秒级完成；需要的计算资源相对少； + 2. 需要重组（reorg）DDL 语句， 这类 DDL 语句的执行不仅需要修改对象的元数据，也需要对于 schema 存储的数据进行处理，例如：加索引，需要扫描全表数据，来创建索引，需要比较多的计算资源与较长的执行时间； + 当前我们仅对于需要重组的 DDL 语句启动了并发执行支持。 +3. 对于启动了并发 DDL 语句支持的 TiDB 集群，DDL 语句间的并发度是如何确定的？ + 目前因为 DDL 等后台任务的执行可能会占用相当的资源，因此我们采取了一个相对保守的策略来确定 DDL 语句执行的并发度 + 1. 对于普通 DDL（general DDL） 语句，我们当前语句并发度为 1（后续将会提供并发执行支持）； + 2. 对于需要重组的 DDL（Reorg DDL）语句，我们的并发度设置规则如下（并发度不允许用户自己设置）： + TiDB DDL owner 节点容器能够使用的 CPU 资源数量的 1/4 与 1 之间的最大值，例如 8C 规格的 TiDB DDL owner 节点，并发度将会是 2。 + +## TiDB DDL 的优先级如何定义? + 由于 DDL 语句，特别是需要重组的 DDL 语句在执行的过程中可能会占用较多计算或者存储引擎资源，从而导致对于前端用户业务的影响。通过对 DDL 任务设置 + - [`tidb_ddl_reorg_priority`](/system-variables.md#tidb_ddl_reorg_priority) + 对与 DDL 等任务如果用户在业务高峰期间，可以将优先级调低，这样 TiDB 集群会通过优先级降低 DDL 对于集群资源的争抢。 + - 其他参数的设置可以参考： + - [`tidb_ddl_reorg_worker_cnt`](/system-variables.md#tidb_ddl_reorg_worker_cnt) + - [`tidb_ddl_reorg_priority`](/system-variables.md#tidb_ddl_reorg_priority) + - [`tidb_ddl_error_count_limit`](/system-variables.md#tidb_ddl_error_count_limit) + - [`tidb_ddl_reorg_batch_size`](/system-variables.md#tidb_ddl_reorg_batch_size) + +## 快速加索引方式的启动常见问题： + 从 TiDB v6.3 开始，我们为 TiDB 用户提供了 快速加索引的模式，可以相对于 v6.1 提升 10倍的速度。我们在 TiDB v6.5 快速加索引模式已经 GA。 + 这里说明一下从低版本升级上来，的一些检查事项： + **TiDB 配置参数**： + - [`temp-dir`](/tidb-configuration-file#temp-dir-new-in-v630) 这个参数用来指定快速加索引模式执行本地磁盘路径。 + - 对于 On Premises 用户， 需要用户提前挂载好 SSD 磁盘，配置好相应路径，然后进行升级操作，重启后检查 TiDB + ```sql +mysql> SHOW CONFIG WHERE type = 'tidb' AND name = 'temp-dir'; ++------+---------------------------------------------------------------------------------------------+----------+-----------+ +| Type | Instance | Name | Value | ++------+---------------------------------------------------------------------------------------------+----------+-----------+ +| tidb | tidb-2:4000 | temp-dir | /tmp/tidb | +| tidb | tidb-1:4000 | temp-dir | /tmp/tidb | +| tidb | tidb-0:4000 | temp-dir | /tmp/tidb | ++------+---------------------------------------------------------------------------------------------+----------+-----------+ +3 rows in set (0.52 sec) +``` + **注意：** 这个是一个配置参数，需要重启 TiDB 节点，上面 `Value` 字段查询出来值应该和用户设置的值应该一致。 + - 对于 Cloud 用户，我们对于能够使用快速加索引功能的使用有一些限制： + +| 描述 | 供应商 | TiDB CPU 规格 | 是否支持快速索引模 | 备注 | +|-----------------------|-----|------------------|------------|------| +| TiDB cloud Dedicated | AWS | 2C vCPU, 4C vCPU | 不支持 | 成本问 | +| | | \>= 8C vCPU | 支持 | | +| | GCP | ALL | 不支持 | | + + TiDB 系统变量设置: + - [`tidb_ddl_enable_fast_reorg`](/system-variables.md#tidb_ddl_enable_fast_reorg-从-v630-版本开始引入) + 这个系统变量在 TiDB v6.5 默认打开。 + - [`tidb_ddl_disk_quota`](/system-variables.md#tidb_ddl_disk_quota-从-v630-版本开始引入)：这个系统变量用来控制快速加索引方式本地磁盘能够使用的限额，对于 on Premises 用户来说可以根实际情况增加这个值。 \ No newline at end of file diff --git a/ticdc/ticdc-faq.md b/ticdc/ticdc-faq.md index 0fae68803343..468d758b3f53 100644 --- a/ticdc/ticdc-faq.md +++ b/ticdc/ticdc-faq.md @@ -438,3 +438,46 @@ TiDB 有事务超时的机制，当事务运行超过 [`max-txn-ttl`](/tidb-conf > **注意：** > > 当同步存储生成列到 Kafka 或存储服务后，再将其写回 MySQL 时，可能会遇到 `Error 3105 (HY000): The value specified for generated column 'xx' in table 'xxx' is not allowed` 错误。为避免该错误，你可以使用 [Open Protocol](/ticdc/ticdc-open-protocol.md) 进行同步。该协议的输出包含[列的 flag 值](/ticdc/ticdc-open-protocol.md#列标志位)，可以区分是否为生成列。 + +## 当频繁出现 `CDC:ErrMySQLDuplicateEntryCDC` 错误时，如何解决？ + +使用 TiCDC 将数据同步到 TiDB 或 MySQL 时，如果上游以特定模式执行 SQL ，可能会遇到如下错误： + +`CDC:ErrMySQLDuplicateEntryCDC` + +出现该错误的原因：TiDB 会将同一事务内对同一行的 `DELETE + INSERT` 操作提交为一个 `UPDATE` 行变更，当 TiCDC 以 UPDATE 的形式向下游同步数据时，尝试交换唯一键值的 `UPDATE` 操作可能会出现冲突。 + +以下表为例： + +```sql +CREATE TABLE data_table ( + id BIGINT(20) NOT NULL PRIMARY KEY, + value BINARY(16) NOT NULL, + UNIQUE KEY value_index (value) +) CHARSET=utf8mb4 COLLATE=utf8mb4_bin; +``` + +如果上游事务尝试交换该表中两行的 `value` 字段： + +```sql +DELETE FROM data_table WHERE id = 1; +DELETE FROM data_table WHERE id = 2; +INSERT INTO data_table (id, value) VALUES (1, 'v3'); +INSERT INTO data_table (id, value) VALUES (2, 'v1'); +``` + +TiDB 内部将会产生两条 `UPDATE` 行变更，因此 TiCDC 会将其转化成两条 `UPDATE` 语句同步到下游： + +```sql +UPDATE data_table SET value = 'v3' WHERE id = 1; +UPDATE data_table SET value = 'v1' WHERE id = 2; +``` + +在执行第二条 `UPDATE` 语句时，如果下游的表中仍然存在 `v1`，会破坏 `value` 列的唯一键约束，从而导致 `CDC:ErrMySQLDuplicateEntryCDC` 错误。 + +如果你频繁遇到 `CDC:ErrMySQLDuplicateEntryCDC` 错误，可以在 `sink-uri` 配置中设置 `safe-mode=true` 参数启用 TiCDC 安全模式： + +``` +mysql://user:password@host:port/?safe-mode=true +``` +在安全模式下，TiCDC 会将 `UPDATE` 操作拆分为 `DELETE + INSERT` 进行执行，从而避免唯一键冲突错误。 \ No newline at end of file