ticdc v6.5.3 upgrade to v6.5.6, `case-sensitive` should change value to `false` or not?

[River2000i]

What did you do?

1. tiup deploy v6.5.3 cluster with cdc
2. create changfeed with default config and do not set any config explicitly
3. upgrade to v6.5.6
4. check changefeed config

What did you expect to see?

the config change default value since v6.5.6: https://docs.pingcap.com/tidb/v6.5/ticdc-changefeed-config#changefeed-configuration-parameters v7.1.3: https://docs.pingcap.com/tidb/v7.1/ticdc-changefeed-config#changefeed-configuration-parameters v7.5.0: https://docs.pingcap.com/tidb/stable/ticdc-changefeed-config#changefeed-configuration-parameters

case-sensitive should change to false for the changefeed created before upgrade?

What did you see instead?

case-sensitive config didn't change after upgrade

Versions of the cluster

Upstream TiDB cluster version (execute SELECT tidb_version(); in a MySQL client):

(paste TiDB cluster version here)

Upstream TiKV version (execute tikv-server --version):

(paste TiKV version here)

TiCDC version (execute cdc version):

(paste TiCDC version here)

[River2000i]

ptal @easonn7

[River2000i]

/assign @benmeadowcroft

[ti-chi-bot[bot]]

@River2000i: GitHub didn't allow me to assign the following users: benmeadowcroft.

Note that only pingcap members with read permissions, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see the contributor guide

In response to this:

/assign @benmeadowcroft

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[River2000i]

@benmeadowcroft ptal~

[JasonWu0506]

/assign @benmeadowcroft

[ti-chi-bot[bot]]

@JasonWu0506: GitHub didn't allow me to assign the following users: benmeadowcroft.

Note that only pingcap members with read permissions, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. For more information please see the contributor guide

In response to this:

/assign @benmeadowcroft

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[benmeadowcroft]

@benmeadowcroft ptal~

Will do

[fubinzh]

/severity moderate

[benmeadowcroft]

/assign @benmeadowcroft

[benmeadowcroft]

With respect to the question on whether the configuration of the changefeed should have been automatically modified during the upgrade, due to the change in the default value, my response is that no, an existing changefeed should not be automatically changed on upgrade.

There are two key reasons for this determination:

First, changing behavior on upgrade should be avoided unless absolutely unavoidable. If we change behavior on upgrade it adds an unplanned operational burden to customers at the time of upgrade. Particularly if this would impact a large number of changefeeds.

Second, the changefeed configuration file is an option passed from the client and is not a persistent server side file as say the TiCDC server configuration file. As such the proper time to apply (or update) defaults is when the changefeed is created or updated. This also ensures that any change in behavior is closely linked to a specific operational action that can be expected to make such a change. If there is unexpected behavior as a result of the changefeed creation or modification (unexpected due to not reading the release notes for example), then the operator who made that change has a better context and opportunity to remediate the issue right away compared to an operator performing an upgrade.

In reviewing the documentation, I do note that this item was called out in the 6.5.6 release notes:

After further testing, the default value of the TiCDC Changefeed configuration item case-sensitive is changed from true to false. This means that by default, table and database names in the TiCDC configuration file are case-insensitive #10047 @sdojjy

Given this I am not sure if there is any change needed to address this issue. The behavior is as expected, and is documented in the release notes.

[asddongmen]

Close since there no more update.