Mysql source code analysis (5): Plugin architecture introduction-reprinted

Document directory

• Main data structures and definitions

Many modules of MySQL are connected to the MySQL core through plugin. Apart from the familiar storage engines, MySQL also supports other types of plugin. This article will give a brief introduction to the relevant content. The main focus is attention-based introduction. The specific details will be mentioned, but will certainly not cover all the details.

Main data structures and definitions

For most data interfaces, macros and constants are defined in include/MySQL/plugin. H. Let's take a look.

First, let's look at the plug-in type:

# Define MYSQL_UDF_PLUGIN 0/* User-defined function */# define plugin 1/* Storage Engine */# define MYSQL_FTPARSER_PLUGIN 2/* Full-text parser plugin */# define MYSQL_DAEMON_PLUGIN 3/ * The daemon/raw plugin type */# define MYSQL_INFORMATION_SCHEMA_PLUGIN 4/* The I _S plugin type */developer-developed plugin must specify one of The above types. Types include user-defined functions, storage engines, full-text parsing, original sound plugin and information schema plugin. The most common is the first three. daemon plugin is generally used to enable a thread in mysqld and work in some cases. Description data interface of a plugin is: struct st_mysql_plugin {int type;/* the plugin type (a MYSQL_XXX_PLUGIN value) */void * info; /* pointer to type-specific plugin descriptor */const char * name;/* plugin name */const char * author;/* plugin author (for show plugins) */const char * descr;/* general descriptive text (for show plugins) */int license;/* the plugin license (PLUGIN_LICENSE_XXX) */int (* init) (voi D *);/* the function to invoke when plugin is loaded */int (* deinit) (void *); /* the function to invoke when plugin is unloaded */unsigned int version;/* plugin version (for show plugins) */struct st_mysql_show_var * status_vars; struct st_mysql_sys_var ** system_vars; void * _ reserved1;/* reserved for dependency checking */}. The main content includes the type, name, initialization/cleaning function, state variable, and system variable definition. However, this data structure is not used directly, but a large number of macros are used to help.

Start of a plugin: # define mysql_declare_plugin (name) \__ mysql_declare_plugin (name, \ builtin _ ## name ##_ plugin_interface_version, \ builtin _ ## name ##_ plugin, \ builtin _ ## name ##_ plugin) plugin definition ends: # define mysql_declare_plugin_end, {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }}_ mysql_declare_plugin different definitions based on whether plugin is a dynamic link plugin or a static link Plugin: # ifndef mysql_dynamic_plugin # DEFINE _ mysql_declare_plugin (name, Version, psize, decls) \ int version = feature; \ int psize = sizeof (struct st_mysql_plugin); \ struct st_mysql_plugin decls [] ={# else # DEFINE _ partition (name, version, psize, decls) \ int _ plugin _ = mysql_plugin_interface_version; \ int _ plugin _ = sizeof (struct st_mysql_plugin); \ struct st_mysql_plugin _ mysql_plugin_declarati ONS _ [] = {# endif special note: "# ifndef mysql_dynamic_plugin". If the plug-in you want to write is dynamically loaded, you need to define this macro during compilation. In general, mysql_declare_plugin declares a struct st_mysql_plugin array. The developer needs to fill in each member of the st_mysql_plugin customized plugin after the macro, and end the array through mysql_declare_plugin_end. Let's take a look at the example plugin/daemon_example/daemon_example.cc. This is a dynamic plugin of the mysql_daemon_plugin type. We noticed that plugin/daemon_example/makefile. Am contains-dmysql_dynam. The specific definitions are as follows: mysql_declare_plugin (daemon_example) {examples, & examples, "daemon_example", "Brian Aker", "daemon example, creates a heartbeat file in mysql-heartbeat.log", examples, daemon_example_plugin_init,/* plugin init * // daemon_example_plugin_deinit,/* plugin deinit * // plugin cleanup function 0x0100/* 1.0 */, null, /* status variables */null,/* syste M variables */null/* config options */} mysql_declare_plugin_end; after preprocess is expanded, this definition is defined as: int _ mysql_plugin_interface_version _ = mysql_plugin_interface_version; \ int _ plugin _ = sizeof (struct st_mysql_plugin); \ struct st_mysql_plugin _ mysql_plugin_declarations _ [] = {mysql_daemon_plugin, & daemon_example_plugin, "daemon_example", "Brian Aker ", "daemon example, creates a heartb Eat beat file in mysql-heartbeat.log ", plugin_license_gpl, daemon_example_plugin_init,/* plugin init * // daemon_example_plugin_deinit, /* plugin deinit * // plugin cleanup function 0x0100/* 1.0 */, null,/* status variables */null, /* system variables */null/* config options */}, {0, 0, 0, 0, 0, 0, 0, 0, 0}; static link plugin is similar, only the variables displayed by the plugin macro have their own names. For MyISAM, a number of plugins called builtin_myisam_plugin is generated. Group. Plugin can define its own variables, including system variables and state variables. For specific examples, you can refer to the statement about the InnoDB plug-in storage/Innobase/handler/ha_innodb.cc, which is easier to understand with plugin. h. In the source code of MySQL, grep mysql_declare_plugin to see which Plugin: $ grep "mysql_declare_plugin (" -- include = *. CC-RNI * plugin/daemon_example/Plugin: 187: mysql_declare_plugin (daemon_example) SQL/ha_partition.cc: 6269: mysql_declare_plugin (partition) SQL/log. cc: 5528: mysql_declare_plugin (BINLOG) SQL/ha_ndbcluster.cc: 10533: mysql_declare_plugin (ndbcluster) Storage/CSV/ha_tina.cc: 1603: mysql_declare_plugin (CSV) Stora Ge/example/ha_example.cc: 893: mysql_declare_plugin (example) Storage/MyISAM/ha_myisam.cc: 2057: memory (MyISAM) Storage/Heap/ha_heap.cc: 746: memory (HEAP) storage/Innobase/handler/ha_innodb.cc: 8231: memory (Innobase) Storage/myisammrg/memory: 1186: memory (myisammrg) Storage/blackhole/ha_blackhole.cc: 356: memory (blackhole) storage/federat Ed/ha_federated.cc: 3368: mysql_declare_plugin (Federated) Storage/archive/ha_archive.cc: 1627: mysql_declare_plugin (archive). Even BINLOG is plugin, but storage plugin is the majority.

Plugin Initialization

In my article about the main function, I also mentioned that plugin_init () is a part of initialization. This is the initialization entry for initializing plugin through all static links. This function is defined in "SQL/SQL _plugin.cc.

Int plugin_init (int * argc, char ** argv, int flags ){

// Initialize the memory allocation pool.

Init_alloc_root (& plugin_mem_root, 4096,409 6 );

Init_alloc_root (& tmp_root, 6, 4096,409 );

// Hash structure Initialization

...

// Initialize the in array during runtime. plugin_dl_array is used to save the dynamic loading of plugin, and plugin_array stores the static link plugin. In addition, each has a maximum of 16 plug-ins.

My_init_dynamic_array (& plugin_dl_array, sizeof (struct st_plugin_dl *), 16 );

My_init_dynamic_array (& plugin_array, sizeof (struct st_plugin_int *),); // initialize the static link plugin for (builtins = mysqld_builtins; * builtins; builtins ++) {// each plugin can also have multiple child plugins. For details, see the plugin statement. For (plugin = * builtins; Plugin-> Info; plugin ++) {register_builtin (plugin, & TMP, & plugin_ptr); // put plugin plugin_array and plugin_hash. // At this time, only CSV or MyISAM plugin is initialized. Plugin_initialize (plugin_ptr); // initialize plugin, call the initialization function of plugin, add the status variable of plugin to the status variable list, and point the plugin member of the system variable to the current active plugin.} // Initialize plugin if (! (Flags & plugin_init_skip_dynamic_loading) {If (opt_plugin_load) plugin_load_list (& tmp_root, argc, argv, opt_plugin_load); // in based on configuration loading. Including finding DLL, loading, searching for symbols, and setting the plugin structure. If (! (Flags & plugin_init_skip_plugin_table) plugin_load (& tmp_root, argc, argv); // load plugin in the system plugin table.} // Initialize the remaining plugin. For (I = 0; I <plugin_array.elements; I ++) {plugin_ptr = * dynamic_element (& plugin_array, I, struct st_plugin_int **); if (plugin_ptr-> state = plugin_is_uninitialized) {If (plugin_initialize (plugin_ptr) {plugin_ptr-> state = plugin_is_dying; * (REAP ++) = plugin_ptr ;}}}...

}

After this function is executed, all the Plugins currently loaded are saved in plugin_array, plugin_dl_array, and plugin_hash. The initialization of this plug-in is complete.

In the plugin_initialize function, each init in's own init function is called (see the previous section ). In particular, for different types of plugins, the parameters of the initialization function are different. This is achieved through a global in_type_initialize indirect layer. This array defines a function for each type of plugin. For example, the storage plugin corresponds to ha_initialize_handlerton, the information scheme corresponds to initialize_schema_table, and then calls the initialization function of plugin in these functions. This intermediate layer initialization function is not defined for plugin of other types, so the initialization function of plugin is called directly.