reference/tools: add ticdc open protocol docs#2284
Merged
Conversation
TomShawn
added
translation/from-docs-cn
Contributor
|
note that there are some change in pingcap/docs-cn#2763 |
zier-one
reviewed
Apr 15, 2020
Contributor
|
@leoppro, @ran-huang, PTAL. |
1 similar comment
Contributor
|
@leoppro, @ran-huang, PTAL. |
ran-huang
reviewed
Apr 20, 2020
|
|
||
| * In most cases, the Row Changed Event of a version is sent only once, but in special situations such as node failure and network partition, the Row Changed Event of the same version might be sent multiple times. | ||
| * Row Changed Events of the same version first sent on the same table are incremented in the order of timestamps (TS) in the Event stream. | ||
| * Resolved Events are periodically broadcasted to each MQ Partition. The Resolved Event means that any Event with TS less than Resolved Event TS has been sent to the downstream. |
Contributor
There was a problem hiding this comment.
I feel less than is weird. Is smaller than or earlier than better?
Suggested change
| * Resolved Events are periodically broadcasted to each MQ Partition. The Resolved Event means that any Event with TS less than Resolved Event TS has been sent to the downstream. | |
| * Resolved Events are periodically broadcasted to each MQ Partition. The Resolved Event means that any Event with a TS less than Resolved Event TS has been sent to the downstream. |
|
|
||
| ## Examples of the Event stream output | ||
|
|
||
| This section shows and displays the output logs of Events. |
Contributor
There was a problem hiding this comment.
Suggested change
| This section shows and displays the output logs of Events. | |
| This section shows and displays the output logs of the Event stream. |
| CREATE TABLE test.t1(id int primary key, val varchar(16)); | ||
| ``` | ||
|
|
||
| From the following Log 1 and Log 3, you can see that the DDL Event is broadcasted to all MQ Partitions. |
Contributor
There was a problem hiding this comment.
Suggested change
| From the following Log 1 and Log 3, you can see that the DDL Event is broadcasted to all MQ Partitions. | |
| From the following Log 1 and Log 3, you can see that the DDL Event is broadcasted to all MQ Partitions, and that the Resolved Event is periodically broadcasted to each MQ Partition. |
| ``` | ||
|
|
||
| + From the following Log 5 and Log 6, you can see that Row Changed Events on the same table might be sent to different partitions based on the primary key, but changes to the same row are sent to the same partition so that the downstream can easily process the Event concurrently. | ||
| + From Log 6, multiple changes to the same row in a transaction only send one Row Changed Event. |
Contributor
There was a problem hiding this comment.
Suggested change
| + From Log 6, multiple changes to the same row in a transaction only send one Row Changed Event. | |
| + From Log 6, multiple changes to the same row in a transaction are only sent in one Row Changed Event. |
|
|
||
| + From the following Log 5 and Log 6, you can see that Row Changed Events on the same table might be sent to different partitions based on the primary key, but changes to the same row are sent to the same partition so that the downstream can easily process the Event concurrently. | ||
| + From Log 6, multiple changes to the same row in a transaction only send one Row Changed Event. | ||
| + Log 8 is a repeated event of Log 7. Row Changed Event might be repeated, but each version of a first Event is sent orderly. |
Contributor
There was a problem hiding this comment.
@leoppro Please confirm whether this is what you mean.
Suggested change
| + Log 8 is a repeated event of Log 7. Row Changed Event might be repeated, but each version of a first Event is sent orderly. | |
| + Log 8 is a repeated event of Log 7. Row Changed Event might be repeated, but the first Event of each version is sent orderly. |
Contributor
|
@leoppro, @ran-huang, PTAL. |
Contributor
|
@leoppro, @ran-huang, PTAL. |
Contributor
Author
|
@ran-huang @leoppro PTAL again, thanks! |
Contributor
|
LGTM |
TomShawn
added
status/can-merge
Contributor
|
/run-all-tests |
Contributor
Author
|
/run-cherry-picker |
sre-bot
pushed a commit
to sre-bot/docs
that referenced
this pull request
Apr 26, 2020
5 tasks
Contributor
|
cherry pick to release-4.0 in PR #2399 |
sre-bot
added a commit
that referenced
this pull request
Apr 26, 2020
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What is changed, added or deleted? (Required)
Add TiCDC Open Protocol documents.
Which TiDB version(s) do your changes apply to? (Required)
If you select two or more versions from above, to trigger the bot to cherry-pick this PR to your desired release version branch(es), you must add corresponding labels such as needs-cherry-pick-4.0, needs-cherry-pick-3.1, needs-cherry-pick-3.0, and needs-cherry-pick-2.1.
What is the related PR or file link(s)?