WL#8007: GCS: Server Interfaces
Affects: Server-5.7 — Status: Complete — Priority: Medium
This worklog is aimed at modularization and creation of interfaces, that shall be useful to not only to GCS but also for future developments in Replication projects.
Functional Requirements: F-1: All interested server plugins shall be informed of the current Server Status progress, in form of a Server callback F-2: All interested server plugins shall be informed of the current Transaction Status progress, in form of a Server callback F-3: All interested server plugins shall be informed of the current SQL Thread progress, in form of a Server callback F-4: A generic interface to apply Replication Events shall be provided F-5: The generic interface must be flexible in order to create a pipeline of event processors Non-Functional Requirements: NF-1: No data shall be changed in the server as result of the interface callbacks
1. Context In the GCS Project, one created several server interfaces in order to decouple server logic from the plugin logic, to avoid having strong dependencies from within the server, thus making the code more modular, allowing GCS to be pluggable. Those ideas have a parallel in the work done with the Semi-Synch Replication plugin. Notable examples as server interfaces from the GCS project are: - Transaction lifetime: an interface was created in order to inform the plugins that a transaction is about to be committed - Server state: an interface was created in order to inform the plugins in which state the server is. For instance, if it is shutting down, starting up, ... 2. QA and performance assessment In order to provide proper coverage of this WL, we added an example plugin: Replication Observers plugin. It will allow us to create tests that will assess the correctness of the implementation of the Server Hooks. The hooks that will be under our tests are: Server State - before_handle_connection: Called before a new client connection. - before_recovery: Called before the server initializes all recovery procedures. - after_engine_recovery: After binlog engine is ready. - after_recovery: Called after the server ends all recovery procedures. - before_server_shutdown: Called before the server starts a shut down. - after_server_shutdown: Called after the server starts a shut down. Transaction - before_commit: Called before a transaction is committed. - before_rollback: Called before a transaction is rollback. - after_commit: Called after a transaction is committed. - after_rollback: Called after a transaction is rollback. Event control and SQL/IO thread handling. - after_reset_slave: Called after a RESET SLAVE is invoked - thread_start: Called when the IO Thread starts - before_request_transmit: Called before the slave requests the events from a master. - after_read_event: Called after an event is received. - after_queue_event: Called after an event is queued. - consumer_thread_stop: Called after the SQL Thread is stopped - thread_stop: Called after the IO Thread is stopped.
Copyright (c) 2000, 2019, Oracle Corporation and/or its affiliates. All rights reserved.