Tài liệu MySQL Administrator''''s Bible- P10 doc

Storage Engines 11 Once this is done you can SELECT from the FEDERATED table and see the rows in the remote table. Limitations of FEDERATED tables Although FEDERATED tables can be extremely useful they do have some limitations. FED- ERATED tables are non-transactional in nature regardless of the support that the remote table might have for transactions. In addition, indexes are not always handled the same for the FEDERATED table as they are for the remote table. FEDERATED tables do not support index prefixes on CHAR, VARCHAR, TEXT,orBLOB columns. There are instances where indexes are not used as expected. Though it is a fairly minor issue, FEDERATED tables do not support the use of ALTER TABLE. To change the table definition of a FEDERATED table you must drop the table and re-create it. Even with these limitations the FEDERATED engine can be very useful when remote data access is needed. NDB storage engine The NDB storage engine is used to build a MySQL Cluster. MySQL Cluster is a shared-nothing, highly available system. MySQL Cluster is designed to avoid a single point of failure. A cluster will contain one or more SQL nodes (traditional MySQL Servers), one or more data nodes, and one or more management servers. For more information about MySQL Cluster, see Chapter 22. Feature summary: ■ Built to provide high availability with redundant sets of data for node failure scenarios. ■ Transactional support. ■ No foreign key support. ■ Row-level locking. ■ Operates either entirely in memory or supports on-disk storage of data columns. Indexes must always be stored in memory. Beginning with MySQL Server version 5.1.24 the standard binaries built by Sun Microsystems will not include the NDB storage engine. Though it is still available with the source code (for now), the code for the NDB storage engine will not be updated to keep pace with changes in the NDB storage engine. If you need to use the NDB storage engine, use the MySQL Cluster server instead of MySQL Server. Archive storage engine The Archive storage engine is a good option for those needing to store data long term or perform data auditing on application operations. For quite some time MySQL has offered an option of using compressed MyISAM tables. There are performance benefits to using compressed 417 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Part III Core MySQL Administration MyISAM tables for read operations, but there are several problems with MyISAM compressed tables: ■ Compressing (or packing) a MyISAM table requires that the database be taken offline while the table is compressed. This is done through the use of the of the myisampack utility from the shell prompt. ■ Compressed MyISAM tables are read-only. You cannot INSERT, DELETE,orUPDATE on a compressed table. Archive tables are, in several ways, an improvement over these older MyISAM packed tables. The designers of the Archive storage engine were definitely looking at what was good about compressed MyISAM tables and improving on the areas of weaknesses of compressed MyISAM tables. Feature summary: ■ Non-transactional. ■ Archive tables allow INSERT operations on the table. However, Archive tables do not allow UPDATE or DELETE operations. For data auditing purposes this is ideal because auditing requirements specify that once data has been created it cannot be changed in any manner. ■ Very good data compression factor. The compression factor on an Archive table is higher than a packed MyISAM table. ■ For reading data, much like the InnoDB engine, the Archive engine uses a snapshot read. This ensures that read operations do not block write operations. ■ The Archive engine uses row-level locking. ■ The Archive storage engine supports only one index. However, in tests, the Archive stor- age engine performs better with read queries than MyISAM packed tables, even when the packed tables have indexes the Archive tables do not. Archive tables use up to four files during operation. All files begin with a filename of the table name. The table definition file has a suffix of .frm. The data file has a suffix of .ARZ. The file with metadata information for the table (if present) has a suffix of .ARM. During table optimiza- tion operations it is also possible that there is a file with a suffix of .ARN. These files will all be located in the directory of the database in which the tables are located. The following shows a modified version of the rental table from the sakila database. Changes were made because Archive tables do not support foreign keys and the rental table had more than one index: mysql> CREATE TABLE `rental_archive` ( -> `rental_id` int(11) NOT NULL AUTO_INCREMENT, -> `rental_date` datetime NOT NULL, -> `inventory_id` mediumint(8) unsigned NOT NULL, -> `customer_id` smallint(5) unsigned NOT NULL, 418 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Storage Engines 11 -> `return_date` datetime DEFAULT NULL, -> `staff_id` tinyint(3) unsigned NOT NULL, -> `last_update` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, -> PRIMARY KEY (`rental_id`) -> ) ENGINE=Archive DEFAULT CHARSET=utf8; Query OK, 0 rows affected (0.01 sec) This creates an archival version of the table. Now to demonstrate the ability to perform INSERT statements but not UPDATE or DELETE statements on an Archive table: mysql> INSERT INTO rental_archive -> (rental_date, inventory_id, customer_id, -> return_date, staff_id) values (NOW(),’1’,’23’,NOW(),’1’); Query OK, 1 row affected (0.00 sec) mysql> SELECT rental_id, rental_date, inventory_id, customer_id -> return_date, staff_id, last_update -> FROM rental_archive\G *************************** 1. row *************************** rental_id: 1 rental_date: 2009-01-16 16:44:41 inventory_id: 1 customer_id: 23 return_date: 2009-01-16 16:44:41 staff_id: 1 last_update: 2009-01-16 16:44:41 1 row in set (0.00 sec) mysql> UPDATE rental SET rental_date=NOW() WHERE rental_id=’1’; ERROR 1031 (HY000): Table storage engine for ’rental_archive’ doesn’t have this option mysql> DELETE FROM rental_archive WHERE rental_id=’1’; ERROR 1031 (HY000): Table storage engine for ’rental_archive’ doesn’t have this option In a nutshell, what is demonstrated here, along with the data compression capabilities, are the two primary reasons for using Archive tables. Blackhole storage engine The Blackhole storage engine does not actually store data in tables as with other storage engines. This might seem to be very counter-intuitive. It is a storage engine that does not store data. But there are uses for this setup. A master server may have an extremely high-write table whose data is only ever used on a slave. For example, session information including where a user clicked may be used in reporting queries, but are never queried on the master server. In this case, the table on the master can be created with ENGINE=BLACKHOLE and the table on the slave can be modified to use any storage 419 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Part III Core MySQL Administration engine. In this way, data updates on the master happen instantaneously, because INSERT, UPDATE,andDELETE statements return immediately as successful (so long as they are valid DML statements according to the table schema). This is a frequently used method of having a high-write table cause almost no extra I/O on the master (the binary logs are still written to). Something quite common with large setups is the use of multiple slaves from a master server. If you have too many slaves this can cause load issues on the master server. You can implement a relay slave that acts as an intermediary to reduce this load. We discuss this in detail in Chapter 16. This relay slave can be configured using the Blackhole storage engine for all tables being replicated. Even though the Blackhole tables do not store any data changes, the binary logs are still written if logging is enabled. The relay slave operates much more efficiently because of the minimization of I/O activity. CSV storage engine The CSV (Comma Separated Value) storage engine is an engine of a decidedly different nature. A CSV data file is simply a text file that can be manipulated with a simple text editor or command-line text tools if needed. One of the primary uses for CSV is for data exchange and fast importing. Feature summary: ■ Plain text data file in CSV format ■ Can have an instantaneous import time ■ Easily imported into programs such as Microsoft Excel ■ Table-level locking ■ No foreign key support ■ Non-transactional ■ Trivial backups and restores (copy the files) ■ Does not support indexing or partitions Three files are created with any CSV table: an .frm file, which contains the table format; a .CSM file, which contains metadata; and the .CSV file, which contains the data. Each of these files has a prefix that consists of the table name. Here is a brief example from a snippet of a data file of a three-field CSV table: "1","Overstreet","Joe" "2","Beal", "Sally" "3","Murphy","Ashton" "4","McGhee", "Sam" 420 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Storage Engines 11 Want an instantaneous import time? Just have the data that you want to be imported stored in the CSV format in an export file. Create a new CSV table with the desired fields and then just copy the export file to the directory of the database. Then move the file to table_name.CSV. Issue a FLUSH TABLES command and the data is instantly available. Working with Storage Engines A number of commands are used specifically to work with any storage engine. These commands are extremely useful in the day-to-day work of a system administrator. CREATE TABLE The CREATE TABLE statement is used to create a database table. You can specify the storage engine that you want to use for the table by using the ENGINE clause or the server will use the default storage engine. For example, to create an InnoDB table: CREATE TABLE innodb_example ( id INTEGER UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT, name VARCHAR(20) NOT NULL ) ENGINE = InnoDB; ALTER TABLE The ALTER TABLE command is used to modify previously created tables. The full syntax for the command is covered in Chapter 4. If you need to change a table type from one storage engine to another the ALTER TABLE command makes this simple. If you executed the previous CREATE TABLE without specifying an ENGINE clause it would create a MyISAM table by default: CREATE TABLE innodb_example ( id INTEGER UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT, name VARCHAR(20) NOT NULL ); After you create the table you realize it needed to be an InnoDB table. To change this you sim- ply run the ALTER TABLE command: mysql> ALTER TABLE innodb_example ENGINE=InnoDB; That is all there is to it! 421 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Part III Core MySQL Administration DROP TABLE The DROP TABLE command is used to drop a table and all its contents. Be careful, because this action cannot be undone. If it is executed inside a transaction the DROP TABLE command will implicitly commit the transaction before performing the actual DROP TABLE command. mysql> DROP TABLE innodb_example; Summary The amazing variety of storage engines available for MySQL Server can be a great benefit to the database administrator. It allows you to choose the storage engine that best fits the needs of your application. You even have the choice of having more than one storage engine at the same time in your database, and having a table on a slave server have a different storage engine than the same table on the master server. This range of options brings complexity. There are typically many options to configure each storage engine. A beginning administrator should concentrate on understanding the MyISAM and InnoDB storage engines because these are going to be the ones you work with most often in a typical MySQL Server environment. Some of the topics that were taught in this chapter include: ■ Pluggable storage engine architecture ■ Storage engine plugins ■ Available storage engines: ■ MyISAM / Merge ■ InnoDB ■ MEMORY ■ Maria ■ Falcon ■ PBXT ■ FEDERATED ■ NDB ■ Archive ■ Blackhole ■ CSV ■ Commands used to work with storage engines 422 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Caching with MySQL IN THIS CHAPTER Implementing Cache Tables Working with the Query Cache Utilizing Memcached O ne of the ways of making queries respond faster is to implement caching. A cache stores frequently used information in a place where it can be accessed faster. For example, a web browser like Firefox uses a cache to store the text, images, and other objects from recently visited websites on your hard drive. When you visit a page you have recently been to, the text and images do not have to be downloaded a second time. Another way objects on web pages are cached is through a caching proxy server such as Squid ( www.squid-cache.org). A caching proxy server is a proxy between the Internet and a set of machines. It eliminates the redundancy of each machine having a private cache. Furthermore, a cache of web objects from sites that all the machines have recently visited are stored, so a machine can benefit from a proxy cache even if it has never visited a particular web page before. Figure 12-1 shows a simplified diagram of a network of desktops that utilize a caching proxy server for web pages. When users visit a web page their computer will first check the web page cache in their browser as described previously. If the page is not stored locally, the next step is to check the Squid cache. If the web page is not stored in the Squid cache, the web page is downloaded from the actual website — storing objects in the Squid and local browser cache along the way. This may sound complicated, but there is very little overhead from check- ing these caches. When a cache can be used it is much faster than downloading content over the Internet. If you have a hundred people behind a caching proxy, there are going to be many cached web objects that can be accessed by someone else. Everyone behind the web caching proxy benefits from the entire cache. Not only is the user experience faster, but because 423 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Part III Core MySQL Administration there is less need to go to the Internet to download a web page, less bandwidth is used. The drawback is sometimes a web page has been updated and a cache has older information. FIGURE 12-1 Internet Caching Proxy Server Like caching in any other application, caching with MySQL is designed to return data from a query quickly. There are three common ways to cache data with MySQL: creating manual cache tables, using internal caching in mysqld, and using the memcached distributed caching system. Implementing Cache Tables Developers and database administrators spend lots of time optimizing queries. However, one aspect of query optimization that is often overlooked is that a simple data access is much faster than a query with calculations, sorting, and aggregations. A cache table is a regular table in a database that stores the results of one or more queries for faster retrieval. Common query results that could be cached in a table are counts, ratings, and summaries. For example, instead of calculating the number of total site visitors every time someone visits a particular web page, you can set an event in the Event Scheduler to calculate the total number of visitors every 30 minutes and store that information in a visitor count table. Then the slower query to calculate count is run once every 30 minutes, and every single time the web page is visited it does a simple query of the visitor count table. For more information on the Event Scheduler and how to create events, see Chapter 7. As an example, assume it takes 4 seconds to calculate the total visitor count and a quarter of a second to return the results from the visitor count cache table. If there are 100 visitors to a site in 30 minutes, it would take 4 seconds per visitor * 100 visitors = 400 seconds of query processing time to run the query for every visitor. However, if you ran the query once every 30 minutes, it would take 4 seconds for the query to run once + 1/4 second to retrieve data from the cache table * 100 visitors to the site = 29 seconds of query processing time. The benefit is obvious. 424 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Caching with MySQL 12 The tradeoff is that the total count may not be 100% accurate. However, it is likely good enough — visitor count is usually used to show how many people have visited the site, and the count still adds value even if it is off by a few percentage points. The decision of whether or not the number is good enough has to be made through a joint effort between the database administrator and the business to determine if this is a reasonable tradeoff. There is one other tradeoff of using the Event Scheduler — the query is run every 30 minutes, regardless of whether or not the information is used. For example, if nobody visits the website for an hour, there is no reason to recalculate the visitor count. If this is an issue you need to overcome, you will have to coordinate with application developers as well to create querying code that uses the following logic: ■ Check the age of the data in the cache table ■ If the data age is 30 minutes or less, use the data in the cache table ■ If the data age is greater than 30 minutes, re-run the query, storing the results and new time in the cache table It is preferable to schedule an event in the Event Scheduler, but for resource-heavy queries that are run on data that does not change very often, it may be necessary to create custom applica- tion code instead. Going back to our example using the Event Scheduler — after the decision to store total visitor count every 30 minutes is made, there is a problem. The business has changed its requirements, and tells you that the count needs to be 100% accurate; it is unacceptable to have the query take 4 seconds, and there is no money in the budget for faster hardware. This issue can be solved by storing the total visitor count for a time period in the past and then adding the count of visitors since the last calculation. For example, at midnight daily, calculate the total visitor count for the previous day. This count will never change once the day is over, so the count for an entire day never needs to be recalculated. The running total of visitors can be calculated as well, and then a 100% accurate count can be done at any time by calculating the total visitor count so far today and adding it to the running total calculated once per day. Computing the count for one day is much less resource-intensive than running full count every time someone visits a page. Not only will this allow for accurate counts of total visitors, but it will allow for easy computa- tion of number of visitors in a given data range — in our example, the number of visitors in a week can be calculated by adding the seven daily totals of visitors. The previous method did not easily allow for this type of data manipulation. Here is an example of how to create such a system: CREATE TABLE visitors_today ( today INT UNSIGNED NOT NULL DEFAULT 0, vcount BIGINT UNSIGNED NOT NULL DEFAULT 0 ) ENGINE=InnoDB; 425 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Part III Core MySQL Administration CREATE TABLE visitors_stored ( vcount BIGINT UNSIGNED NOT NULL DEFAULT 0, vcount_date DATE NOT NULL PRIMARY KEY ) ENGINE=MyISAM; The visitors_stored table holds a historic record of the count of visitors per day. There can only be one entry per day. The visitors_today table holds the current count of visitors so far today (in the today field) and the total count of visitors up to today (in the vcount field). With each new visitor, update the visitors_today.count field: UPDATE visitors_today SET today = today + 1; To retrieve the current total visitor count: SELECT today + vcount FROM visitors_today; Every day at midnight, schedule an event that: ■ Inserts a new row with yesterday’s date and count in the visitors_stored table ■ Calculates and stores the total running count in visitors_today.vcount ■ Resets the vistors_today.today field to zero Here is a sample event that updates the current and historic visitor count tables: CREATE EVENT update_vcount ON SCHEDULE EVERY 1 DAY STARTS ’2009-01-01 00:00:00’ DO BEGIN INSERT INTO visitors_stored (vcount, vcount_date) SELECT today, CURRENT_DATE() - INTERVAL 1 DAY FROM visitors_today; UPDATE visitors_today set today=0, vcount=( SELECT SUM(vcount) as vcount FROM visitors_stored); END Do not forget to enable the Event Scheduler with SET GLOBAL event_scheduler=’ON’,and recall from Chapter 7 that you will need to change the DELIMITER to define an event with multiple statement events. Also, for the system to function it must be initialized; at minimum you must populate the visitors_today table. If today already had 37 visitors and the total number of visitors at the start of the day was 1,638,492, the following would populate the table properly: INSERT INTO visitors_today (today, vcount) VALUES (37,1638492); For a new system, simply use INSERT INTO visitors_today (today, vcount) VALUES (0,0); . 426 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. [...]... Core MySQL Administration the backup files to the appropriate location on your host server and starting mysqld If the snapshot was created while mysqld was shut down, the restore will produce a normal startup If the snapshot was created while mysqld was running, mysqld may think it is recovering from a crash and perform the recovery process The basic procedure for performing a backup of a running MySQL. .. ZFS) ALL ALMOST HOT FAST FAST LEAST FLEXIBLE mysqlhotcopy MyISAM MOSTLY COLD FAST FAST FLEXIBLE mysqldump The mysqldump program has been a backup tool for mysqld for a long time It provides a logical backup of entire database servers, individual databases, individual tables, or even subsets of data using the where option The logical backup created using mysqldump is often called a data dump The output... normally if($result == null) { $query = mysql_ query($sql) or die (mysql_ error()." : $sql"); if (mysql_ num_rows($query)> 0) { $result = mysql_ fetch_object($query); //store the result in memcache $memcache->set($key,$result,0,1800); $content = $result->content; } } ?> Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark 437 12 Part III Core MySQL Administration The code first checks... the code for a database query that does not use memcached: Here is one way to integrate memcached: . NDB storage engine is used to build a MySQL Cluster. MySQL Cluster is a shared-nothing, highly available system. MySQL Cluster is designed to avoid a single. ftp://ftp.tummy.com/pub/ python-memcached/ MySQL UDFs Memcached Functions for MySQL http://tangent.org/586/Memcached_ Functions_for _MySQL. html Though we do not have