MySQL Day 11: Intro to Connection Management

· Overall Flow
· Main Components
∘ Connection_acceptor
∘ Connection_handler_manager
∘ Channel_info
∘ Protocol
· Code
· Conclusion

This is going to be a very basic flow of how connection managment works in MySQL. I will be adding more details as in when I learn more.

Overall Flow

+-----------------------------------------------------+
|         mysqld.cc                                   |
+-----------------------------------------------------+
| int mysqld_main()                                   |
| {                                                   |
|   mysqld_socket_acceptor =                          |
|     new Connection_acceptor(                        |
|       new Mysqld_socket_listener());                <-- creates listener
|                                                     |
|   mysqld_socket_acceptor->connection_event_loop();  <-- enters loop
|   return 1;                                         |
| }                                                   |
+-----------------------------------------------------+
                    |
                    v
+----------------------------------------------------+
|       connection_acceptor.h                        |
+----------------------------------------------------+
| void connection_event_loop()                       |
| {                                                  |
|   Connection_handler_manager *mgr =                |
|     Connection_handler_manager::get_instance();     <-- gets manager
|                                                    |
|   while (!connection_events_loop_aborted()) {       <-- loop
|     Channel_info *channel_info =                   |
|       m_listener->listen_for_connection_event();   <-- accepts connection from listener
|     if (channel_info != nullptr)                   |
|       mgr->process_new_connection(channel_info);   <-- hand off
|   }                                                |
| }                                                  |
+----------------------------------------------------+
                    |
                    v
+------------------------------------------------+
|     connection_handler_manager.cc              |
+------------------------------------------------+
| void Connection_handler_manager::              |
|      process_new_connection(channel_info)      |
| {                                              |
|   if (m_connection_handler->                   |
|         add_connection(channel_info))          <-- forward to handler
|   {                                            |
|     // Success                                 |
|   }                                            |
| }                                              |
+------------------------------------------------+
                    |
                    v
+--------------------------------------------------------+
|     connection_handler_one_thread.cc                   |
+--------------------------------------------------------+
| bool One_thread_connection_handler::add_connection(    |
|       Channel_info *channel_info)                      |
| {                                                      |
|   THD *thd = channel_info->create_thd();               <-- create thread context
|                                                        |
|   if (do_command(thd))                                 <-- execute command
|     return false;                                      |
|   return true;                                         |
| }                                                      |
+--------------------------------------------------------+

Main Components

Connection_acceptor

Connection_acceptor uses

→ Mysqld_socket_listener for socket listnening

→Connection_handler_manager for process_new_connection(channel_info)

Connection_handler_manager

Connection_handler_manager uses

→ Connection_handler → One_thread_connection_handler → THD + do_command

Channel_info

/**
  This abstract base class represents connection channel information
  about a new connection. Its subclasses encapsulate differences
  between different connection channel types.

  Currently we support local and TCP/IP sockets (all platforms),
  named pipes and shared memory (Windows only).
*/

Protocol

class Protocol {
  /**
    Result set sending functions

    @details Server uses following schema to send result:
                  ... sending metadata ...
                             | start_result_metadata(...)
                             | start_row()
                             | send_field_metadata(...)
                             | end_row()
              ... same for each field sent ...
                             | end_result_metadata(...)
                             |
                  ... sending result ...
                             | start_row(...)
                             | store_xxx(...)
           ... store_xxx(..) is called for each field ...
                             | end_row(...)
        ... same for each row, until all rows are sent ...
                             | send_ok/eof/error(...)
    However, a protocol implementation might use different schema. For
    example, Protocol_callback ignores start/end_row when metadata is being
    sent.
   */

  virtual void start_row() = 0;
  virtual bool end_row() = 0;
  virtual void abort_row() = 0;
  virtual void end_partial_result_set() = 0;
};

Code

innodb_lite/sql/conn_handler at feature/lite · cpporchard/innodb_lite

Conclusion

Connection management is quite similar to socket managment or Spring Boot. I guess, thats why Pinot has the web api’s build using JAX-RS.