Open BugenZhao opened 1 year ago
@StrikeW Pls take a look
@StrikeW Is this fixed already by #12868 ?
@StrikeW Is this fixed already by #12868 ?
I have spotted the cause of this issue, which is not related to #12868. Will submit a PR soon.
Update to this issue: the reason why it takes a while before receiving upstream events is that we use the same identity to create a new connector in the process of ReplceTable
. In Debezium, the database.server.name
property should be unique across different instance of connectors, otherwise it will retry multiple times to register the JMX metric. We may find ways to patch the code of Debezium to reduce the number of retry times.
Update to this issue: the reason why it takes a while before receiving upstream events is that we use the same identity to create a new connector in the process of
ReplceTable
. In Debezium, thedatabase.server.name
property should be unique across different instance of connectors, otherwise it will retry multiple times to register the JMX metric. We may find ways to patch the code of Debezium to reduce the number of retry times.
Can we generate a unique id for database.server.name
?
@StrikeW Is the issue fixed?
@StrikeW Is the issue fixed?
I think not. Will take a look this month.
@StrikeW Any updates?
https://github.com/risingwavelabs/risingwave/blob/64602acb400cc79f6641de285a186d219cf0605d/e2e_test/source/cdc_inline/alter/postgres_alter.slt#L31-L47
Considering that we have to rebuild the actors of the table, I suppose there'll be a procedure that we need to create a new entry in the meta's split manager. Is there a possibility that we need to wait for a tick interval before the new source executors can reconnect to the CDC again?