Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better handle KA signals between primary and replica during full data sync #1861

Open
ranshid opened this issue Mar 18, 2025 · 0 comments
Open

Comments

@ranshid
Copy link
Member

ranshid commented Mar 18, 2025

In #1737 an issue related to how we retry openssl write retries was introduced.
The issue was related to the fact that retried write requests in openssl should always point to the same data with at least the same size length as the previouse blocked write attempt on the socket (see https://docs.openssl.org/master/man3/SSL_write for details)

In #1737 we correctly handled the regular case of a blocked write while writing some data stream on the socket.
However, there are cases were application will try to write "out-of-band" data on the stream which was blocked before while writing the regular data stream. For example this could happen when the primary is writing a keepalive indication to the replication stream while is was blocked with some pending data not yet sent and is still pending in the openssl lib buffers.

For this reason a debugAssert planned to be introduced as part of #1737 to cause assertion when an attempt to send data with smaller size than the pending not written data was not included in the fix (some information in this thread).

The target of this issue is to solve the existing known cases of sending out-of-band data while socket is blocked with pending unwritten data and re-introduce the debugAssert to prevent new code from falling to the same pitfall.
Example approach would be to make sure to flush all replication pending data before we start the fullsync in the replication primary flow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant