MySQL Enterprise Solutions phần 10 doc

■■ optimize(): Called during processing of OPTIMIZE TABLE to defragment and otherwise improve the table. By default, it returns HA_ADMIN_NOT_IMPLEMENTED. ■■ analyze(): Called during processing of ANALYZE TABLE to update key distribution statistics. By default, it returns HA_ADMIN_NOT_ IMPLEMENTED. ■■ backup(): Backs up table files to a directory. It is implemented only for MyISAM tables and used in handling the BACKUP TABLE command. ■■ restore(): Restores the table backed up with the BACKUP TABLE com- mand. It is used in processing the RESTORE TABLE command. ■■ dump(): Dumps the table in binary format across the network. It is used by the master to send a copy of the table to the slave. It is currently imple- mented only for MyISAM tables. ■■ deactivate_non_unique_index(): Temporarily disables non-unique index updates to speed up data import. It is used in handling ALTER TABLE DISABLE_KEYS and to speed up LOAD DATA INFILE and multi- row inserts. The index is reenabled and updated with a call to activate_all_index(). ■■ activate_all_index(): Re-enables all keys and updates them based on the inserted data. It will be called to finalize a multirow insert and LOAD DATA INFILE with disabled keys, or through the invocation of ALTER TABLE ENABLE KEYS. ■■ net_read_dump(): Reads the binary table dump sent by dump() and re- creates the table on the slave. It is currently implemented only for the MyISAM handler. ■■ update_table_comment(): Updates the comment field on the table with its stored definition. It is used in ALTER TABLE. ■■ append_create_info(): Appends extra information that cannot normally be deduced from the regular table structures and that is available only to the handlers via the output of SHOW CREATE TABLE command. ■■ get_foreign_key_create_info(): Obtains the string used for creating the foreign keys from the handler if the handler supports them. Currently, InnoDB is the only handler that supports foreign keys. ■■ init_table_handler_for_HANDLER(): Initializes the table to prepare it for the use of the HANDLER command. The HANDLER command is a new feature in MySQL 4.0 that allows you to access the records by iterating through a key instead of using a SELECT, UPDATE, or DELETE command. ■■ free_foreign_key_create_info(): Frees the string returned by get_ foreign_key_create_info(). It is currently implemented only in the InnoDB handler. Exploring MySQL Server Internals 358 ■■ index_flags(): Returns the capability bitmask for the given index, with each bit indicating that a certain functionality is supported. ■■ max_key_part_length(): Returns the maximum length of a key part in a composite key. ■■ min_record_length(): Returns the length of the shortest record sup- ported by the handler. ■■ low_byte_first(): Reports whether the integers in the internal representa- tion are in the big-endian or the little-endian byte order. The default is 1 (little-endian). ■■ is_crashed(): Checks if the table was cleanly closed before the last shut- down. ■■ auto_repair(): Reports whether the handler has the auto-repair capability. ■■ rename_table(): Changes the name of the table. The default implementa- tion goes through the table file extensions reported by bas_ext(), append- ing each to the table name and renaming the resulting file according to the name of the new table. If your storage engine does not store the table in a set of files unique to the given table or if the name of the file is not related to the name of the table, you should reimplement this method. ■■ delete_table(): Does the handler-specific part of dropping the table. It is called when processing the DROP TABLE command. ■■ lock_count(): Reports how many tables are actually locked by the han- dler. Normally the value is 1, which is what the default implementation returns. However, the MERGE table handler may lock more than one table (see ha_myisammrg.cc for details). Once you have implemented all pure virtual methods, along with the non-pure virtual methods appropriate for your storage interface, you will be able to cre- ate tables of your own custom type with CREATE TABLE tbl_name ( ) TYPE=your_custom_type; and perform regular SQL queries on them. However, as we have mentioned earlier, the information in this chapter is just a set of general directions and guidelines. To actually be able to complete the task, you have to delve into some specific issues that are beyond the scope of this book. We can point you to a few places in the source that you can study to gain that information. We recommend you study the following (all files are in the sql directory): ■■ handler.h and handler.cc can help you become more familiar with the han- dler members and default implementations of the virtual methods that are not pure. General Guidelines for Extending the Source 359 ■■ ha_myisam.h, ha_myisam.cc, ha_heap.h, ha_heap.cc, ha_innodb.h, ha_inn- odb.cc, ha_berkeley.h, ha_berkeley.cc, ha_myisammrg.h and ha_myisammrg.cc include functional handler implementation examples. You may want to follow the engine-specific calls into the sources where they are implemented. To facilitate the task of finding them, you may want to use a tool like Doxygen, or if you do not want to take the time to install and learn a new tool, a simple grep can take you a long way. ■■ Pay particular attention to the comments in ha_innodb.cc at the top of each method implementation. They provide additional insights into the dif- ficult issues you may have to deal with. ■■ sql_select.cc, sql_table.cc, filesort.cc, and sql_base.cc show you the con- text of handler method invocations. Those are not the only files where han- dler methods are invoked, but that is where the bulk of the calls originates. ■■ table.h familiarizes you with members of struct st_table (later typedefed to TABLE).The most important member you want to follow throughout the source is record, which is an array of three one-record buffer pointers. Those three one-record buffers are used very extensively while interfacing with the handlers. ■■ table.cc shows the details of how MySQL opens a table and initializes the TABLE structure in openfrm(). Particularly look for the initialization of file with a call to get_new_handler(). ■■ sql_base.cc shows how the record is assembled in fill_record(). Then study item.h and item.cc to see the definition and implementation of Item_field. Taking the code further apart, take a look at field.h and field.cc and study the definition and implementation of Field along with its subclasses. Field is responsible for converting the in-memory processing field format to the storage format and vice versa. Maintaining Your Code Modifications If you modify the source of MySQL, you will still likely want to keep up with the new features and bug fixes in the newer versions of MySQL. Fortunately, Bit- Keeper makes it very convenient to do so. The additional benefit of using Bit- Keeper is having your own changes managed by a very powerful version-control system. Let’s examine some of the basic BitKeeper operations involved in keeping your code base up-to-date. Once you have reached some point of consistency in your code modification process (e.g., it compiles and passes some simple tests, or you have reached the point where you believe the code is stable enough to put into production), it is Exploring MySQL Server Internals 360 time to commit your changes. To do this, you run bk citool from anywhere within the source directory (all BitKeeper commands we mention in this sec- tion must be run from within the tree unless otherwise stated). You will see a dialog window showing all of the changes you have made for each file in diff format, and prompting you to comment on each file as well as the entire set of changes. After you have entered the comments, click the Commit button twice (each time with a single click). The changes will be committed, and the dialog window will disappear. To synchronize your source with the central repository in its current state, exe- cute bk pull. In many cases, this may not be quite exactly what you want to do, since the centralized repository is more often than not in a mid-release state. Although all MySQL AB developers are required to run their code through a regression test suite before they push their local changes into the main reposi- tory, sometimes mistakes are made, and the mid-release tree could contain a bug. Additionally, developers are required to run the test suite only on their development machine, which means they can unknowingly introduce a bug that simply does not manifest itself on their platform but is present on others. Mid-release commits are also not tested with Purify, which means that the chances of having a memory leak or some other bad code error are higher. For those reasons, it is preferable to synchronize with release snapshots rather than an arbitrary mid-release point. To synchronize with a certain release version of MySQL, you would have to do a small maneuver, at least until BitKeeper begins to support pulling up to the given changeset as opposed to pulling everything. First, clone the snapshot of the main tree corresponding to the version you are interested in: bk clone -rmysql-version bk://work.mysql.com:7001 /path/to/bkdir/mysql-version This command is for the 4.0 tree. For 3.23, change the port from 7001 to 7000. Replace version with the actual version number (without the alpha, beta, or gamma suffix). Replace /path/to/bkdir with the name of an existing directory when you want the tree cloned. Then pull from the newly cloned repository into your development tree with the changes. Do so by changing into the develop- ment tree directory, and then execute bk pull /path/to/bkdir/mysql-version In some cases, your changes may conflict with the ones in the central reposi- tory in a way that BitKeeper would not know what to do. In this case, you would have to run bk resolve and tell BitKeeper what you want to do about the con- flicts. Sometimes BitKeeper does not do the right thing when merging changes. If you suspect this might happen, you should do pk pull -i /path/to/bkdir/mysql- version and then run bk resolve. Maintaining Your Code Modifications 361 Sometimes you may have pulled changes that break something in your code, or are undesirable in some other way. With bk sccstool, BitKeeper makes it quite easy to track down when and how this happened, and who did it. You can see the graph of changesets, and you can click on each and examine them in more detail. You can also select individual files and see for each line who modified it last and in what changeset. After you have found the trouble line, you can go to the changeset that has introduced it, read the comments, look at what else the changeset has modified, and then decide what you are going to do to fix it. Conclusion We have provided a basic introduction into working with the MySQL server code base. As you work with the source, you will become more familiar with it, and will see its strengths and weaknesses. Sometimes you may have a question about the code, or you may want to submit a patch, or just suggest a way to improve it. If you have anything to say about MySQL source, e-mail your com- ments to internals@lists.mysql.com. You do not have to subscribe to be able to post. It is my hope that your experience with the source will be not just challenging but also enjoyable, and that you will take advantage of the opportunity to both learn and contribute. Exploring MySQL Server Internals 362 M igration to MySQL from another database is always possible, but it is not always easy. The two most difficult challenges are porting an appli- cation that depends on features that MySQL does not currently sup- port, and being locked into a client language that does not allow the code to be easily modified to work with MySQL. The key to determining the feasibility of migration is examining the potential roadblocks to see if they exist, and if they do, whether there is a reasonable way to eliminate them. Answering the follow- ing questions will help you determine the ease with which you can migrate to MySQL: ■■ Does your application depend on subqueries? If it does and the subqueries are sufficiently simple that you could write a parser to detect and rewrite them to joins or sequences of queries using a temporary table, then migra- tion might be worthwhile. ■■ Does your application depend on triggers? If so, is it feasible to replace them with equivalent user-level code? If you can do this, migration might be worth a try. ■■ Does your application depend on views? If it does, there is no easy workaround short of completely removing the dependency. ■■ Does your application depend on stored procedures? If yes, consider writ- ing a parser that will translate the currently used stored procedures into equivalent client code and then incorporate it into your application. ■■ What language is the client written in and what connectivity standard is being used? Perl/DBI, ODBC, and JDBC are the most encouraging Migration Notes APPENDIX A 363 answers—the porting of the client code becomes a matter of changing the data source in the connect call and perhaps fixing a few cases of depen- dency on some database-specific behavior. If the client is written in another language that uses a replaceable library for database operations, the porting can be accomplished by writing a special library that will trans- late the semantics of the old database calls into that of MySQL and replac- ing the old connectivity library with the new one. The feasibility of porting then is determined by how close the old database API resembles that of MySQL, and how easy it is to implement MySQL connectivity in terms of the syntax of the old database. The worst case is when you are using a scripting language that does not have any intermediate layers that you can replace. In this case, the only solution is to write an automatic code con- verter if the application is too big; otherwise, you would need to rewrite the code from scratch. In the past, the lack of transaction support has been a stumbling block on the migration path. With the availability of InnoDB tables, this stumbling block now is largely removed, although you may occasionally experience some portability issues when InnoDB uses a different paradigm from the database the code was originally written in. These issues can be dealt with on a case-by-case basis. It is recommended that if your code makes heavy use of transactions that you purchase MySQL support contract with InnoDB support at https://order.mysql.com. This way, you are likely to have any potential prob- lems solved quickly. Many potential users ask whether MySQL will be able to handle the load and/or the data volume after migration from another database. In most cases, MySQL will improve your application’s performance. Occasionally, you may run into a query that was optimized for your old database and needs to be rewritten for MySQL. These issues can be addressed on a case-by-case basis using sugges- tions found in Chapter 15, “Analyzing and Improving Server Performance.” To actually perform a migration to MySQL, follow these general steps: ■■ Export the data from the database you have been using into a set of SQL statements that will re-create the tables and populate them with the data. The actual sequence of the set depends on the database you are using. You should consult the documentation for more specific instructions. ■■ Use MySQL’s GRANT command to create users and give them appropriate privileges. ■■ If the SQL export does not include CREATE DATABASE statements, then create the needed databases. ■■ Import the data into MySQL using mysqldump. Migration Notes 364 ■■ Adapt your client code to connect to MySQL. In some cases (Peri/DBI, ODBC, JDBC), this will be as simple as changing the DSN value. In other cases, some ingenuity may be required. The basic principle is to substitute the original API layer with the one that will translate the old calls to their MySQL equivalents. ■■ Address the MySQL missing features issues. For example, rewrite the sub- queries as joins or a sequence of queries using a temporary table. Test your new application setup and deal with any remaining portability issues as they arise. Migration Notes 365 T roubleshooting any system or application is a complex task. It is impos- sible to list every potential issue and give its solution in this book. Instead, this appendix explains several concepts that will help you deter- mine the category of issue you face. Then you will be able to make efficient use of a variety of resources; first and foremost is the troubleshooting section of the MySQL online manual (www.mysql.com/doc/en/Problems.html) to find your solution. Issues with MySQL can be categorized into three groups: functionality, stability, and performance. Functionality MySQL functionality issues usually manifest themselves as queries result sets that are not quite what you expected. The two obvious reasons for unexpected query results are bugs and incorrect expectations. The first thing you should do is isolate the problem using the smallest possible test case: a sequence of SQL statements that demonstrate the aberrant result on any installation of MySQL (not just on your system). In other words, the test case must be fully contained and should not depend on any previously created users, tables, or databases, other than those created during a default installation of MySQL. Once you have the test case, it is recommended that you consult the SQL stan- dards to verify that your query is written correctly for the results you expect, Troubleshooting Notes APPENDIX B 367 [...]... www .mysql. com /doc: MySQL online manual www .mysql. com/downloads: MySQL main download page www .mysql. com/documentation/lists.html: Information about MySQL mailing lists http://order .mysql. com/: Place to order commercial support for MySQL from MySQL AB mysql@ lists .mysql. com: General MySQL mailing list Subscription is not required to post Make sure to follow the posting guidelines from Chapter 1 www .mysql. com /doc/ en/C.html:... 147 mysql_ connect() function (PHP), 141, 146–147 mysql_ create_table(), 335 mysqld ended message, 43 mysql_ data_seek() C/C++, 117 PHP, 141 mysql_ db_name() function (PHP), 142 mysql_ debug() function (C/C++), 117 mysql_ delete(), 335 mysqld_show(), 335 mysqldump utility, 313–316 mysql_ dump_debug_info() function (C/C++), 117 mysqldumpslow script, 275–277 mysql_ errno() function C/C++, 117, 123 PHP, 142 mysql_ error()... MySQL_ FIELD structure (C/C++), 117 mysql_ field_count() function (C/C++), 118 mysql_ field_flags() function (PHP), 143 389 mysql_ field_len() function (PHP), 143 mysql_ field_name() function (PHP), 143 MYSQL_ FIELD_OFFSET structure, 117 mysql_ field_seek() function C/C++, 118 PHP, 143 mysql_ field_table() function (PHP), 144 mysql_ field_tell() function (C/C++), 118 mysql_ field_type() function (PHP), 144 mysql_ free_result()... function (PHP), 145 mysql_ rm_table(), 335 MYSQL_ ROW structure, 117 MYSQL_ ROW_OFFSET structure, 117 mysql_ row_seek() function (C/C++), 121 mysql_ row_tell() function (C/C++), 121 mysql_ select(), 336–337, 338 mysql_ select_db() function C/C++, 121, 123 PHP, 145 mysql_ shutdown() function (C/C++), 121 mysql_ stat() function (C/C++), 121 mysql_ store_result() function (C/C++), 121, 123–124 mysqlsyseval test configuring,... C/C++, 118 PHP, 144, 147 mysql_ get_client_info() function C/C++, 118 PHP, 144 mysql_ get_host_info() function C/C++, 118 PHP, 144 mysql_ get_proto_info() function C/C++, 119 PHP, 144 mysql_ get_server_info() function C/C++, 119 PHP, 144 mysqlhotcopy command, 311–313 mysql_ info() function (C/C++), 119 mysql_ init() function (C/C++), 119, 122 mysql_ init_query(), 331 mysql_ insert(), 335 mysql_ insert_id() function... 119 PHP, 144 mysql_ kill() function (C/C++), 119 mysql_ list_dbs() function (C/C++), 119 mysql_ list_dbs function (PHP), 144 mysql_ list_fields() function C/C++, 119 PHP, 144 390 Index mysql_ list_processes() function, 119, 335 mysql_ list_tables() function C/C++, 119 PHP, 144 mysql_ lock_tables(), 334 mysql_ num_fields() function C/C++, 120 PHP, 145 mysql_ num_rows() function C/C++, 120 PHP, 145 mysql_ options()... function (C/C++), 120 mysql_ parse(), 330–331, 332 mysql_ pconnect() function (PHP), 145, 146–147 mysql_ ping() function (C/C++), 120 mysql_ query() function C/C++, 120, 123 PHP, 145 mysql_ real_connect() function (C/C++), 120, 122–123 mysql_ real_escape_string() function (C/C++), 120, 123 mysql_ real_query() function (C/C++), 120, 123 mysql_ reload() function (C/C++), 120 MYSQL_ RES structure, 116 mysql_ result()... 162–163 MYSQL structure, 116 initializing (C/C++), 122 mysql- test-run test suite common results, 50–53 reporting failures, 53–55 running, 49–50 mysql- test subdirectory, 327 mysql_ afetch_assoc() function (PHP), 142 mysql_ affected_rows() C/C++, 117 PHP, 141 mysql_ alter_table(), 335 mysql_ change_user() function (C/C++), 117 mysql_ character_set_name() function (C/C++), 117 mysqlcheck utility, 321 mysql_ close()... utility, 210 211 unoptimized record lookup, 215 HEAP tables, 208–209 InnoDB tables, 208 joins, 209– 210 key lookup methods, 208 key reads, 208 manual key selection, 208 MyISAM tables, 208 output, 210 overview, 208 WHERE clause, 209 optimizing schema, 237–238 Web applications avoiding dynamic execution, 109 avoiding long queries, 107 108 avoiding unnecessary queries, 108 109 persistent connections, 109 – 110. .. 118, 123 PHP, 142, 146–147 mysql_ escape_string() function (PHP), 142, 147–148 mysql_ execute_command(), 335 mysql_ fetch_array() function (PHP), 142 mysql_ fetch_field() function C/C++, 118 PHP, 142–143 mysql_ fetch_field_direct() function (C/C++), 118 mysql_ fetch_fields() function (C/C++), 118 mysql_ fetch_lengths() function C/C++, 118 PHP, 143 mysql_ fetch_object function (PHP), 143 mysql_ fetch_row() function . and foremost is the troubleshooting section of the MySQL online manual (www .mysql. com /doc/ en/Problems.html) to find your solution. Issues with MySQL can be categorized into three groups: functionality,. to bugs@lists .mysql. com. Make sure to use mysqlbug script to compose the bug report. If large tables are required to duplicate the bug, upload them to ftp://support .mysql. com/ pub /mysql/ secret. Bugs. then create the needed databases. ■■ Import the data into MySQL using mysqldump. Migration Notes 364 ■■ Adapt your client code to connect to MySQL. In some cases (Peri/DBI, ODBC, JDBC), this will