void rewindBinaryLogClient(ChangeEventSourceContext context, BinlogPosition position) {
        try {
            if (context.isRunning()) {
                LOGGER.debug("Rewinding binlog to position {}", position);
                client.disconnect();
                client.setBinlogFilename(position.getFilename());
                client.setBinlogPosition(position.getPosition());
                client.connect();
            }
        } catch (IOException e) {
            LOGGER.error("Unexpected error when re-connecting to the MySQL binary log reader", e);
        }
    }
Apply the include/exclude GTID source filters to the current {@link #source() GTID set} and merge them onto the
currently available GTID set from a MySQL server.

The merging behavior of this method might seem a bit strange at first. It's required in order for Debezium to consume a
MySQL binlog that has multi-source replication enabled, if a failover has to occur. In such a case, the server that
Debezium is failed over to might have a different set of sources, but still include the sources required for Debezium
to continue to function. MySQL does not allow downstream replicas to connect if the GTID set does not contain GTIDs for
all channels that the server is replicating from, even if the server does have the data needed by the client. To get
around this, we can have Debezium merge its GTID set with whatever is on the server, so that MySQL will allow it to
connect. See <a href="https://issues.jboss.org/browse/DBZ-143">DBZ-143</a> for details.

This method does not mutate any state in the context.

@param availableServerGtidSet the GTID set currently available in the MySQL server
@param purgedServerGtid the GTID set already purged by the MySQL server
@return A GTID set meant for consuming from a MySQL binlog; may return null if the SourceInfo has no GTIDs and therefore
        none were filtered
inlong-sort/sort-flink/sort-flink-v1.13/sort-connectors/mysql-cdc/src/main/java/io/debezium/connector/mysql/MySqlStreamingChangeEventSource.java