Rechercher dans le manuel MySQL
29.2.1 Types of Plugins
The plugin API enables creation of plugins that implement several capabilities:
The following sections provide an overview of these plugin types.
Storage Engine Plugins
The pluggable storage engine architecture used by MySQL Server enables storage engines to be written as plugins and loaded into and unloaded from a running server. For a description of this architecture, see Section 16.11, “Overview of MySQL Storage Engine Architecture”.
For information on how to use the plugin API to write storage engines, see MySQL Internals: Writing a Custom Storage Engine.
MySQL has a built-in parser that it uses by default for
full-text operations (parsing text to be indexed, or parsing a
query string to determine the terms to be used for a search).
The built-in full-text parser is supported with
InnoDB
and MyISAM
tables.
MySQL also has a character-based ngram full-text parser that
supports Chinese, Japanese, and Korean (CJK), and a word-based
MeCab parser plugin that supports Japanese, for use with
InnoDB
and MyISAM
tables.
For full-text processing, “parsing” means extracting words (or “tokens”, in the case of an n-gram character-based parser) from text or a query string based on rules that define which character sequences make up a word and where word boundaries lie.
When parsing for indexing purposes, the parser passes each word to the server, which adds it to a full-text index. When parsing a query string, the parser passes each word to the server, which accumulates the words for use in a search.
The parsing properties of the built-in full-text parser are described in Section 12.9, “Full-Text Search Functions”. These properties include rules for determining how to extract words from text. The parser is influenced by certain system variables that cause words shorter or longer to be excluded, and by the stopword list that identifies common words to be ignored. For more information, see Section 12.9.4, “Full-Text Stopwords”, and Section 12.9.6, “Fine-Tuning MySQL Full-Text Search”.
The plugin API enables you to use a full-text parser other than the default built-in full-text parser. For example, if you are working with Japanese, you may choose to use the MeCab full-text parser. The plugin API also enables you to provide a full-text parser of your own so that you have control over the basic duties of a parser. A parser plugin can operate in either of two roles:
The plugin can replace the built-in parser. In this role, the plugin reads the input to be parsed, splits it up into words, and passes the words to the server (either for indexing or for token accumulation). The ngram and MeCab parsers operate as replacements for the built-in full-text parser.
You may choose to provide your own full-text parser if you need to use different rules from those of the built-in parser for determining how to split up input into words. For example, the built-in parser considers the text “case-sensitive” to consist of two words “case” and “sensitive,” whereas an application might need to treat the text as a single word.
The plugin can act in conjunction with the built-in parser by serving as a front end for it. In this role, the plugin extracts text from the input and passes the text to the parser, which splits up the text into words using its normal parsing rules. This parsing is affected by the
innodb_ft_
orxxx
ft_
system variables and the stopword list.xxx
One reason to use a parser this way is that you need to index content such as PDF documents, XML documents, or
.doc
files. The built-in parser is not intended for those types of input but a plugin can pull out the text from these input sources and pass it to the built-in parser.
It is also possible for a parser plugin to operate in both roles. That is, it could extract text from noncleartext input (the front end role), and also parse the text into words (thus replacing the built-in parser).
A full-text plugin is associated with full-text indexes on a
per-index basis. That is, when you install a parser plugin
initially, that does not cause it to be used for any full-text
operations. It simply becomes available. For example, a
full-text parser plugin becomes available to be named in a
WITH PARSER
clause when creating individual
FULLTEXT
indexes. To create such an index
at table-creation time, do this:
Or you can add the index after the table has been created:
The only SQL change for associating the parser with the index
is the WITH PARSER
clause. Searches are
specified as before, with no changes needed for queries.
When you associate a parser plugin with a
FULLTEXT
index, the plugin is required for
using the index. If the parser plugin is dropped, any index
associated with it becomes unusable. Any attempt to use a
table for which a plugin is not available results in an error,
although DROP TABLE
is still
possible.
For more information about full-text plugins, see
Section 29.2.4.4, “Writing Full-Text Parser Plugins”. MySQL
8.0 supports full-text plugins with
MyISAM
and
InnoDB
.
A daemon plugin is a simple type of plugin used for code that should be run by the server but that does not communicate with it. MySQL distributions include an example daemon plugin that writes periodic heartbeat messages to a file.
For more information about daemon plugins, see Section 29.2.4.5, “Writing Daemon Plugins”.
INFORMATION_SCHEMA
plugins enable the
creation of tables containing server metadata that are exposed
to users through the INFORMATION_SCHEMA
database. For example, InnoDB
uses
INFORMATION_SCHEMA
plugins to provide
tables that contain information about current transactions and
locks.
For more information about
INFORMATION_SCHEMA
plugins, see
Section 29.2.4.6, “Writing INFORMATION_SCHEMA Plugins”.
MySQL replication is asynchronous by default. With semisynchronous replication, a commit performed on the master side blocks before returning to the session that performed the transaction until at least one slave acknowledges that it has received and logged the events for the transaction. Semisynchronous replication is implemented through complementary master and client plugins. See Section 17.3.11, “Semisynchronous Replication”.
For more information about semisynchronous replication plugins, see Section 29.2.4.7, “Writing Semisynchronous Replication Plugins”.
The MySQL server provides a pluggable audit interface that enables information about server operations to be reported to interested parties. Audit notification occurs for these operations (although the interface is general and the server could be modified to report others):
Write a message to the general query log (if the log is enabled)
Write a message to the error log
Send a query result to a client
Audit plugins may register with the audit interface to receive notification about server operations. When an auditable event occurs within the server, the server determines whether notification is needed. For each registered audit plugin, the server checks the event against those event classes in which the plugin is interested and passes the event to the plugin if there is a match.
This interface enables audit plugins to receive notifications only about operations in event classes they consider significant and to ignore others. The interface provides for categorization of operations into event classes and further division into event subclasses within each class.
When an audit plugin is notified of an auditable event, it receives a pointer to the current THD structure and a pointer to a structure that contains information about the event. The plugin can examine the event and perform whatever auditing actions are appropriate. For example, the plugin can see what statement produced a result set or was logged, the number of rows in a result, who the current user was for an operation, or the error code for failed operations.
For more information about audit plugins, see Section 29.2.4.8, “Writing Audit Plugins”.
MySQL supports pluggable authentication. Authentication plugins exist on both the server and client sides. Plugins on the server side implement authentication methods for use by clients when they connect to the server. A plugin on the client side communicates with a server-side plugin to provide the authentication information that it requires. A client-side plugin may interact with the user, performing tasks such as soliciting a password or other authentication credentials to be sent to the server. See Section 6.2.17, “Pluggable Authentication”.
Pluggable authentication also enables proxy user capability, in which one user takes the identity of another user. A server-side authentication plugin can return to the server the name of the user whose identity the connecting user should have. See Section 6.2.18, “Proxy Users”.
For more information about authentication plugins, see Section 29.2.4.9, “Writing Authentication Plugins”.
The MySQL server provides an interface for writing plugins that test passwords. Such a plugin implements two capabilities:
Rejection of too-weak passwords in statements that assign passwords (such as
CREATE USER
andALTER USER
statements).Assessing the strength of potential passwords for the
VALIDATE_PASSWORD_STRENGTH()
SQL function.
For information about writing this type of plugin, see Section 29.2.4.10, “Writing Password-Validation Plugins”.
MySQL supports the use of protocol trace plugins: client-side plugins that implement tracing of communication between a client and the server that takes place using the client/server protocol.
For more information about protocol trace plugins, see Section 29.2.4.11, “Writing Protocol Trace Plugins”.
MySQL Server supports query rewrite plugins that can examine and possibly modify statements received by the server before the server executes them. A query rewrite plugin takes statements either before or after the server has parsed them.
A preparse query rewrite plugin has these characteristics:
The plugin enables rewriting of SQL statements arriving at the server before the server processes them.
The plugin receives a statement string and may return a different string.
A postparse query rewrite plugin has these characteristics:
The plugin enables statement rewriting based on parse trees.
The server parses each statement and passes its parse tree to the plugin, which may traverse the tree. The plugin can return the original tree to the server for further processing, or construct a different tree and return that instead.
The plugin can use the
mysql_parser
plugin service for these purposes:To activate statement digest calculation and obtain the normalized version of statements independent of whether the Performance Schema produces digests.
To traverse parse trees.
To parse statements. This is useful if the plugin constructs a new statement string from the parse tree. The plugin can have the server parse the string to produce a new tree, then return that tree as the representation of the rewritten statement.
For more information about plugin services, see Section 29.3, “MySQL Services for Plugins”.
Preparse and postparse query rewrite plugins share these characteristics:
If a query rewrite plugin is installed, the
--log-raw
option affects statement logging as follows:If a plugin rewrites a statement, the server decides whether to write it to the binary log (and thus to any replication slaves) based on the rewritten statement, not the original statement. If a plugin rewrites only
SELECT
statements toSELECT
statements, there is no impact on binary logging because the server does not writeSELECT
statements to the binary log.If a plugin rewrites a statement, the server produces a
Note
message that the client can view usingSHOW WARNINGS
. Messages have this format, wherestmt_in
is the original statement andstmt_out
is the rewritten statement:Query 'stmt_in' rewritten to 'stmt_out' by a query rewrite plugin
MySQL distributions include a postparse query rewrite plugin
named Rewriter
. This plugin is rule based.
You can add rows to its rules table to cause
SELECT
statement rewriting. For
more information, see
Section 5.6.4, “The Rewriter Query Rewrite Plugin”.
Query rewrite plugins use the same API as audit plugins. For more information about audit plugins, see Section 29.2.4.8, “Writing Audit Plugins”.
MySQL Server supports keyring plugins that enable internal server components and plugins to securely store sensitive information for later retrieval.
All MySQL distributions include a keyring plugin named
keyring_file
. MySQL Enterprise Edition distributions include
additional keyring plugins. See Section 6.4.4, “The MySQL Keyring”.
For more information about keyring plugins, see Section 29.2.4.12, “Writing Keyring Plugins”.
Nederlandse vertaling
U hebt gevraagd om deze site in het Nederlands te bezoeken. Voor nu wordt alleen de interface vertaald, maar nog niet alle inhoud.Als je me wilt helpen met vertalingen, is je bijdrage welkom. Het enige dat u hoeft te doen, is u op de site registreren en mij een bericht sturen waarin u wordt gevraagd om u toe te voegen aan de groep vertalers, zodat u de gewenste pagina's kunt vertalen. Een link onderaan elke vertaalde pagina geeft aan dat u de vertaler bent en heeft een link naar uw profiel.
Bij voorbaat dank.
Document heeft de 26/06/2006 gemaakt, de laatste keer de 26/10/2018 gewijzigd
Bron van het afgedrukte document:https://www.gaudry.be/nl/mysql-rf-plugin-types.html
De infobrol is een persoonlijke site waarvan de inhoud uitsluitend mijn verantwoordelijkheid is. De tekst is beschikbaar onder CreativeCommons-licentie (BY-NC-SA). Meer info op de gebruiksvoorwaarden en de auteur.
Referenties
Deze verwijzingen en links verwijzen naar documenten die geraadpleegd zijn tijdens het schrijven van deze pagina, of die aanvullende informatie kunnen geven, maar de auteurs van deze bronnen kunnen niet verantwoordelijk worden gehouden voor de inhoud van deze pagina.
De auteur Deze site is als enige verantwoordelijk voor de manier waarop de verschillende concepten, en de vrijheden die met de referentiewerken worden genomen, hier worden gepresenteerd. Vergeet niet dat u meerdere broninformatie moet doorgeven om het risico op fouten te verkleinen.