Pro MySQL experts voice in open source phần 10 ppt

Solutions The following are a few ways of discovering the cause of a broken MySQL connection: •To verify that it was a connection problem, reconnect and issue the statement again. If the statement runs successfully, you probably encountered a timeout. •If the connection is broken when you run the query a second time, check the value of your max-allowed-packet setting. You can also look in the error log to see if a Packet too large message is logged. If so, increase the max-allowed-packet value. • Check with your database administrator to see if he killed your connection. ■Note The database administrator should immediately contact users with a notification that their connec- tion was causing a problem and was killed, and help them work through the problem. •If you don’t have a problem with the packet size, carefully examine the syntax of your query. MySQL will sometimes close the connection if the query syntax is incorrect. Make sure all of your join fields are specified. You may want to reduce the complexity of the query, and gradually build it piece by piece to get back to the original complex query. •If, in building a query, you find that some combination of valid SQL syntax generates this error, you may have stumbled into a MySQL bug (rare, but possible). See the “How to Report MySQL Bugs” section later in this chapter for information about finding and reporting bugs to MySQL AB. For more information, refer to http://dev.mysql.com/doc/mysql/en/gone-away.html and http://dev.mysql.com/doc/mysql/en/communication-errors.html. Troubleshooting Start, Restart, and Shutdown Issues In this section, we’ll discuss common problems related to starting and shutting down the server properly, including the following: •Determining whether the server crashed •Problems starting the MySQL server •Problems stopping the MySQL server •Unexpected restarts ■Note While MySQL aims to make every server installation a bump-free and quick process, you may run into trouble when installing or upgrading your server. See Chapter 14 for information that will help if you have problems installing or upgrading a MySQL database. CHAPTER 20 ■ TROUBLESHOOTING 661 505x_Ch20_FINAL.qxd 6/27/05 3:40 PM Page 661 Did the Server Crash? Depending on the message you get from the client, you may not be sure if the database server restarted or if you just had an issue with a client or a query. It is sometimes confusing trying to determine how significant the event was. Although a client connection getting closed is important to resolve, most administrators would consider a server restart far more serious. Being aware of where the problem occurred is important. You have several ways to determine when the server last restarted. One way is to use the mysqladmin version command and check the uptime to determine if the server has recently restarted. Output from this command is shown in Listing 20-7. As you can see on the Uptime line, the server has been up for ten days, meaning that, in this example, the message you just got from the client was not because the server restarted. Listing 20-7. Output from mysqladmin version # mysqladmin version mysqladmin Ver 8.41 Distrib 5.0.6-beta, for unknown-linux-gnu on x86_64 Server version 5.0.6-beta-max-log Protocol version 10 Connection Localhost via UNIX socket UNIX socket /tmp/mysql.sock Uptime: 10 days 21 hours 58 min 21 sec Threads: 1 Questions: 858 Slow queries: 0 Opens: 0 Flush tables: 1 Open tables: 3 Queries per second avg: 0.001 You can also get the uptime in seconds from within the MySQL shell, by using the SHOW VARIABLES LIKE 'uptime' command. The output of this command is shown in Listing 20-8. Listing 20-8. Uptime from MySQL Client mysql> SHOW VARIABLES like 'uptime'; + + + | Variable_name | Value | + + + | Uptime | 84472 | + + + 1 row in set (0.00 sec) Another method for seeing if the database has recently restarted, and to get the history of activity over time, is to check the error log. Listing 20-9 shows the output of the log with an egrep for messages that indicate the server has stopped, started, or restarted. If you find unex- plained entries in this output, you should look more closely at the error log and general query log to compare database activity with the unexplained server restarts to determine what might be the cause of the problem. CHAPTER 20 ■ TROUBLESHOOTING662 505x_Ch20_FINAL.qxd 6/27/05 3:40 PM Page 662 Listing 20-9. egrep of Error Log shell> egrep "(ended|started|restarted)" promysql.err 050501 13:16:10 mysqld started 050501 15:51:32 mysqld ended 050501 15:51:33 mysqld started 050502 15:41:29 mysqld ended 050502 15:41:31 mysqld started 050502 15:41:43 mysqld ended 050502 16:02:04 mysqld started 050502 16:04:50 mysqld ended 050502 16:05:03 mysqld started 050505 17:48:40 mysqld ended 050505 17:54:07 mysqld started For more information about the mysqld_safe startup script, see http://dev.mysql.com/ doc/mysql/en/mysqld-safe.html. For what to do if MySQL keeps crashing, refer to http:// dev.mysql.com/doc/mysql/en/crashing.html. Problems Starting MySQL Server Have you ever started the MySQL server only to find that, before you can connect, the MySQL server daemon ended? In MySQL version 5.0.4, the mysql.server script changed a bit to pre- vent the server from indicating it started up only to shut right back down. As of MySQL 5.0.4, when you issue the start command, you wait until the database has started, and then get a success message: /etc/init.d/mysql start Starting MySQL SUCCESS! Evidence of the Problem The most common way to find that your server won’t start is to wait in suspense as the server startup process runs, and then see it finally indicates an error occurred: /etc/init.d/mysql start Starting MySQL ERROR! If you aren’t using the startup script, the common indicator is the mysql ended message in the logs or on the console where the server was started. Also, starting the server using the MySQL binary itself will keep the process and messages in the forefront, as shown in Listing 20-10. CHAPTER 20 ■ TROUBLESHOOTING 663 505x_Ch20_FINAL.qxd 6/27/05 3:40 PM Page 663 Listing 20-10. Running MySQL Without a Startup Script ./bin/mysqld 050430 14:56:32 [Warning] Can't create test file /data/mysql/promysql.lower-test ./bin/mysqld: Can't change dir to '/data/mysql/' (Errcode: 2) 050430 14:56:32 [ERROR] Aborting Seeing the error about /data/mysql shown in Listing 20-10, you would check what’s going on in the /data/mysql directory where your data files are stored. You might learn that the data directory is not properly mounted. Solutions Following are some steps to take when you have problems starting up MySQL: • Check to see if MySQL is already running, or if the network port you are using for MySQL is being used by another process. • Check the error logs to determine if any abnormal event was logged. •Be sure your directories and data file permissions are set for the MySQL user and group. •If the startup fails with an unknown option, fix the offending option. • Check to see if there are missing data or log directories specified in the configuration file. •If all of your existing options seem correct and your directories are fine, but you still are not seeing any log information, start MySQL using just the daemon itself with ./bin/mysqld, and see what kind of output is generated. For more information about the MySQL startup script, see http://dev.mysql.com/doc/ mysql/en/mysql-server.html. Problems Stopping MySQL Server In rare cases, you may find that you cannot seem to stop the MySQL server. Most often, this is related to a thread being busy in the database. Evidence of the Problem You’ll see this problem when you attempt to stop the MySQL server: sudo /etc/init.d/mysql stop And instead of the typical, few seconds to stop the database, the wait continues until your database indicates it can’t be stopped: Killing mysqld with pid 32441 Wait for mysqld to exit gave up waiting! Or, with the MySQL 5.0.4 and later mysql.server script, you’ll see that the stop process ends in an error: /etc/init.d/mysql stop Shutting down MySQL ERROR! CHAPTER 20 ■ TROUBLESHOOTING664 505x_Ch20_FINAL.qxd 6/27/05 3:40 PM Page 664 Solutions Here are a few things to check and do if you are having a problem shutting down MySQL: •You may have a thread that is busy and is preventing the server from stopping. Use the SHOW PROCESSLIST command to identify queries that are in progress. Killing the connec- tion may be what’s required to stop MySQL. •Before stopping the database, stop resources (like Apache) that maintain connections to MySQL that could prevent the database from stopping. •Is the MySQL server actually running? Look at processes and verify that MySQL is run- ning. If the PID file exists, the error will come back even if the process isn’t running. If your server stopped abnormally and didn’t have a chance to remove the PID file, it will attempt to shut down as if it were running. ■Caution When you’re having issues with shutting down a server, you may be tempted to use the operat- ing system to force MySQL to exit. If MySQL won't shut down because it's busy writing data and you force it to, you may end up with corrupt or missing data. Use the operating system-level process termination com- mand or tool only as a last resort. For more information, see http://dev.mysql.com/doc/mysql/en/mysql-server.html. Problems with Unexpected Restarts A server unexpectedly restarting can lead to a lot of stress. If you are in an environment where every second counts, not knowing when the next server restart is going to happen may be unac- ceptable. For other database uses, unexpected restarts are less damaging, but still unnerving. If you have experienced unexpected restarts, you’ll want to know what caused them and how to prevent them in the future. Evidence of the Problem Although a restart by mysqld_safe happens quickly, it is easily noticed by an application under heavy usage when connections can’t be made for the small amount of time the server is down during the restart. If a restart goes unnoticed, or to figure out the exact timing, you can see the entry (or entries) by doing a grep "restarted" host.err. Solutions If you have problems with unexpected server restarts, the following items may help you resolve the problem: •Not having enough memory can cause unexpected restarts. This can happen if MySQL needs more memory than is physically available on the server or another process is consuming a lot of memory. If you have a system that monitors your server’s resources, check to see whether the low amount of memory available correlates to the times when the MySQL server restarted. CHAPTER 20 ■ TROUBLESHOOTING 665 505x_Ch20_FINAL.qxd 6/27/05 3:40 PM Page 665 •Server restarts are a sign of corruption in the database tables. You should go through the steps to check the status of your tables and repair them if necessary. The next sec- tion provides more information about data corruption. •Perform troubleshooting tasks on the operating system and hardware. A defective disk, damaged RAID controller, or faulty RAM can affect MySQL’s ability to function and may cause the database to restart during certain failures. • Check the following MySQL documentation: • What to do if MySQL keeps crashing: http://dev.mysql.com/doc/mysql/en/ reproduceable-test-case.html •Table maintenance: http://dev.mysql.com/doc/mysql/en/table-maintenance.html • Check MyISAM tables: http://dev.mysql.com/doc/mysql/en/myisamchk-syntax.html •Repair MyISAM tables: http://dev.mysql.com/doc/mysql/en/repair.html Resolving Data Corruption As hard as MySQL developers work to perfect the database software, and database administra- tors work to keep their systems protected, data corruption does occur. The MySQL development team takes data corruption very seriously and provides a set of instructions to follow to create a reproducible bug that will allow them to identify where the corruption is happening. Evidence of the Problem The corrupted data files often show up in the form of a server crash or unexpected restart. They cause queries to fail or to return unexpected results (or no results). A more proactive approach for databases using the MyISAM storage engine is to regularly run the mysqlcheck script to determine if any tables are corrupted. The following are some reasons that you might experience data file corruption: • The server was killed in the middle of an update. •A bug caused MySQL to stop while writing to disk. • An external program is manipulating the data files. •Multiple servers are pointed to the same data files. •A corrupted data file caused the server to act improperly and corrupt other data. •A storage engine bug caused bad data to be written. • The operating system, hardware, or disks may be faulty. CHAPTER 20 ■ TROUBLESHOOTING666 505x_Ch20_FINAL.qxd 6/27/05 3:40 PM Page 666 Solutions If you encounter a corrupt data file, here are some areas to look into: •Be sure you have backups of your data. Yes, once you’ve discovered there is corruption it may be too late, but we hope you’ve had enough foresight to create regular backups (see Chapter 17 for details about backing up MySQL). •If you are using MyISAM tables, run the mysqlcheck or myisamchk script to repair the table. •If you can still get your database to run and use the table, do a mysqldump of the table, DROP the table, and then import the data from the dump. (Chapter 17 describes how to use mysqldump.) •Follow MySQL’s steps to create a repeatable situation and contact MySQL with the nec- essary information. You can find these steps at http://dev.mysql.com/doc/mysql/en/ reproduceable-test-case.html. You can refer to the MySQL documentation for checking and recovering MyISAM tables, at http://dev.mysql.com/doc/mysql/en/myisamchk-syntax.html and http://dev.mysql.com/ doc/mysql/en/crash-recovery.html, respectively. How to Report MySQL Bugs It is possible that, in your use of MySQL, you encounter a bug. MySQL doesn’t release software marked as production-ready until all known fatal bugs are resolved. MySQL defines a fatal bug as one that causes the server to crash under normal use, gives the wrong answer for a normal query, or contains a security problem. That being said, there is an active bug-tracking system that allows database users to submit bugs and track their status as they go through the system. If you think you’ve found a bug, follow the steps outlined in the MySQL documentation for submitting a bug report (http://dev.mysql.com/doc/mysql/en/bug-reports.html). This involves the following steps: •Make sure it’s a repeatable bug (http://dev.mysql.com/doc/mysql/en/reproduceable- test-case.html). •Search the existing documentation and mailing lists to see if there is a resolution. •Search through the bug reports to see if it has been reported (http://dev.mysql.com/doc/mysql/en/open-bugs.html). •Finally, submit the bug report with information about your environment and how to duplicate the bug. The MySQL team follows the bug-tracking system very closely and usually gets to work on a bug report within just a few hours. CHAPTER 20 ■ TROUBLESHOOTING 667 505x_Ch20_FINAL.qxd 6/27/05 3:40 PM Page 667 Support Options A chapter on troubleshooting wouldn’t be complete without mentioning support options. Each organization has different needs, and you have a wide spectrum of options when you’re looking for support for your MySQL installation. What matches your needs will depend on what assistance you require and when you require it. Here are some support options: Mailing lists: If you have some expertise with MySQL, and your troubleshooting priorities allow you time to search and post, you can get a lot of information and help from the MySQL mailing lists. The collective group of people who participate have a great deal of expertise, and response time is typically pretty good (provided you have good manners). Even if you have a critical problem that is happening in real time, it’s still worth trying out a mailing list to get help exploring the issue and formulating a strategy to resolve it. There are several MySQL mailing lists. Unless you have a specific question about a particular piece of MySQL that has its own mailing list, the general user mailing list is the place to go. For a list of all of MySQL mailing lists, along with the list archives and instructions for subscription, visit http://lists.mysql.com/. Consultants: If you are running an instance of MySQL, but don’t have the time, interest, or ability to resolve a problem, a consultant may be the right person to step in. A web search for “MySQL consultant” brings up hundreds of links leading to people who have experi- ence with MySQL and are looking for opportunities to apply their knowledge and experience. Help from MySQL AB: If you are looking for MySQL expertise, why not turn to the folks who are building the database? MySQL AB offers several consulting packages, including a one-day rapid response service for urgent needs (a certified consultant will work with you on troubleshooting, performance, architecture, or any of your MySQL needs). Another option from MySQL AB is the MySQL Network (http://www.mysql.com/network/), a serv- ice that gives you access to production support and MySQL developers to help solve your unique issues. The MySQL Network also provides certified releases of the MySQL database. Summary Troubleshooting a database server can be a stressful experience, especially if the problem is occurring in your production environment and affecting the availability of your application. A good database administrator is familiar with the details of MySQL and knows exactly what to do when a situation arises. This includes having a thorough knowledge of how to use the troubleshooting tools and where to look for answers. We spent a significant portion of the chapter discussing the various tools and logs that are the foundation for dealing with specific problems. We then went through a number of differ- ent common problems and gave details on possible causes and solutions. Our goal was to provide some detailed information, as well as to show you examples of the methodology for working through problems. As you combine the knowledge of MySQL administration with the honing of your real- time problem-solving skills, you will become more capable of surviving a problem in your database without unnecessary stress and wasted time. This, in turn, will please the users of your database, as well as your manager, customers, and clients. CHAPTER 20 ■ TROUBLESHOOTING668 505x_Ch20_FINAL.qxd 6/27/05 3:40 PM Page 668 MySQL Data Dictionary In this chapter, we’ll be taking a closer look at a feature of MySQL 5 that’s receiving consider- able attention. As of version 5.0.2, the INFORMATION_SCHEMA virtual database is available, which offers a standardized way of reading meta information about the database server and its schemas. In this chapter, we’ll examine what exactly the INFORMATION_SCHEMA data store is, how you can use it, and what information is contained inside it. Before we go further, we want to discuss a few terms used in this chapter. The discussion of a database server’s meta information commonly involves the following terms: • metadata • data dictionary or system catalog • INFORMATION_SCHEMA The definition of metadata is simply data about other data. Metadata describes or sum- marizes another piece of data. Examples of metadata include the number of rows in a table, the type of index structure used on a set of columns, or the statement used to create a stored procedure. Each of these pieces of data describes another piece of data or structure. All major database vendors have a repository, or container, for metadata, but different database vendors refer to this repository differently. The two most common terms, however, are data dictionary and system catalog. We consider them synonymous, but when referring to the metadata repository, we’ll use the term data dictionary. The term INFORMATION_SCHEMA describes the ANSI standard interface to the database server’s metadata. The INFORMATION_SCHEMA is not an actual schema (database), but the data contained inside this virtual database can be accessed just like any other database on the server. In this way, the INFORMATION_SCHEMA interface acts as a standardizing component for accessing information about the database server and its actual schema. The “tables” inside this virtual database aren’t tables at all, but rather table-like data that is pulled from a variety of sources, including the underlying mysql system database, and the MySQL server system variables and counters. In this way, the INFORMATION_SCHEMA tables are more like views than tables. If you’re coming from a Microsoft SQL Server background, you’ll recognize this concept, as the INFORMATION_SCHEMA supported by Microsoft SQL Server are views that pull actual data from the Microsoft SQL Server system tables, such as sys_objects and sys_indexes. INFORMATION_SCHEMA views are read-only, partly because the data contained in the INFORMATION_SCHEMA views isn’t contained in a single location, but instead pulled from the storage areas noted earlier. 669 CHAPTER 21 ■ ■ ■ 505x_Ch21_FINAL.qxd 6/27/05 3:41 PM Page 669 In this chapter, we’ll be looking at the following topics related to the new INFORMATION_ SCHEMA feature of MySQL 5: •Benefits of a standardized interface • The INFORMATION_SCHEMA views •Examples of usage Benefits of a Standardized Interface Before we get into the specific tables that comprise the MySQL Data Dictionary, we want you to understand why the data dictionary has been added as a feature to the MySQL 5 source code. For those of you without much experience with MySQL’s SHOW commands, the transition to using the INFORMATION_SCHEMA database might take some getting used to, but we highly rec- ommend taking the time to do so. There are three main advantages to the INFORMATION_SCHEMA interface versus the SHOW commands: •Adherence to standards •Using SELECT to retrieve metadata •More information than SHOW commands Adherence to Standards MySQL’s SHOW commands are proprietary and not standards-compliant. By contrast, the INFORMATION_SCHEMA interface is a standard outlined by ANSI/ISO as part of the SQL-99 and SQL:2003 standards. One advantage to complying with these standards is that applications that rely on querying for metadata—for example, a monitoring application—can be written in a portable fashion. The databases supporting INFORMATION_SCHEMA views are MySQL, Microsoft SQL Server, and, to some extent, IBM’s DB2 database. Hopefully, in the future, all major database vendors will move to full compliance, and application code can be truly vendor-agnostic. Having metadata queries written for the INFORMATION_SCHEMA interface is a proactive stance for future portability needs. To adhere completely to the SQL standard, MySQL’s implementation of the INFORMATION_ SCHEMA shows columns for which MySQL has no equivalent data. For these columns—for instance, the INFORMATION_SCHEMA.TABLES.TABLE_CATALOG column—MySQL simply displays a NULL value, because MySQL has no concept of a database “catalog.” In addition, MySQL displays certain additional data pieces in the INFORMATION_SCHEMA output where MySQL stores nonstandard or extension information. This is done to provide complete equivalency to the MySQL SHOW commands. We’ll detail later where the MySQL implementation diverges from the ANSI standard. Using SELECT to Retrieve Metadata Perhaps the best reason to use the INFORMATION_SCHEMA views is that you can access metadata through your standard SQL SELECT statements. Instead of various SHOW commands—such as SHOW TABLES, SHOW FULL COLUMNS, and so on—you access the data through the old familiar SELECT statement. CHAPTER 21 ■ MYSQL DATA DICTIONARY670 505x_Ch21_FINAL.qxd 6/27/05 3:41 PM Page 670 [...]... username ORDINAL_POSITION: 1 POSITION _IN_ UNIQUE_CONSTRAINT: NULL 1 row in set (0.00 sec) The fields contained in INFORMATION_SCHEMA.KEY_COLUMN_USAGE are as follows: • CONSTRAINT_CATALOG: Always NULL • CONSTRAINT_SCHEMA: Name of the database containing the constraint • CONSTRAINT_NAME: Name of the constraint • TABLE_CATALOG: Always NULL • TABLE_SCHEMA: Name of the database containing the table in which... was created • ROUTINE_COMMENT: Any comment issued at procedure creation time • DEFINER: User who created the procedure in user@host format There’s no SHOW command equivalent for the data contained in INFORMATION_SCHEMA ROUTINES However, the mysql. proc system table contains all the information available in the view INFORMATION_SCHEMA.VIEWS The INFORMATION_SCHEMA.VIEWS view details information about... highlight the information available from the following INFORMATION_SCHEMA views: • INFORMATION_SCHEMA.SCHEMATA • INFORMATION_SCHEMA.TABLES • INFORMATION_SCHEMA.TABLE_CONSTRAINTS • INFORMATION_SCHEMA.COLUMNS • INFORMATION_SCHEMA.KEY_COLUMN_USAGE • INFORMATION_SCHEMA.STATISTICS • INFORMATION_SCHEMA.ROUTINES • INFORMATION_SCHEMA.VIEWS • INFORMATION_SCHEMA.CHARACTER_SETS • INFORMATION_SCHEMA.COLLATIONS • INFORMATION_SCHEMA.COLLATION_CHARACTER_SET_APPLICABILITY... • INDEX_SCHEMA: Name of the database in which the index is housed It’s always the same as TABLE_SCHEMA • INDEX_NAME: Name of the index within the schema • SEQ _IN_ INDEX: Shows the position of this column within the index key, starting at position 1 • COLUMN_NAME: Name of the column in the index key • COLLATION: The column’s collation Will either be A for an ascending index order, or NULL for descending... the information that a SELECT * FROM ➥ INFORMATION_SCHEMA.TABLES would output INFORMATION_SCHEMA.TABLE_CONSTRAINTS The INFORMATION_SCHEMA.TABLE_CONSTRAINTS view shows columns related to all tables for which a constraining index exists Listing 21-3 shows a DESCRIBE and a simple SELECT from this view Listing 21-3 INFORMATION_SCHEMA.TABLE_CONSTRAINTS mysql> DESCRIBE INFORMATION_SCHEMA.TABLE_CONSTRAINTS;... 505x_Ch21_FINAL.qxd 6/27/05 3:41 PM Page 695 CHAPTER 21 ■ MYSQL DATA DICTIONARY Listing 21-16 ShowIndexSelectivity.sql SELECT t.TABLE_SCHEMA , t.TABLE_NAME , s.INDEX_NAME , s.COLUMN_NAME , s.SEQ _IN_ INDEX , ( SELECT MAX(SEQ _IN_ INDEX) FROM INFORMATION_SCHEMA.STATISTICS s2 WHERE s.TABLE_SCHEMA = s2.TABLE_SCHEMA AND s.TABLE_NAME = s2.TABLE_NAME AND s.INDEX_NAME = s2.INDEX_NAME ) AS "COLS _IN_ INDEX" , s.CARDINALITY... POSITION _IN_ UNIQUE_CONSTRAINT: Either NULL, or the position of the column in a referenced FOREIGN KEY constraint that happens to be a UNIQUE INDEX The KEY_COLUMN_USAGE data is useful for identifying column positioning in constraints on tables There’s no equivalent SHOW command that returns the same information INFORMATION_SCHEMA.STATISTICS The INFORMATION_SCHEMA.STATISTICS view displays information regarding the indexes... later in the chapter INFORMATION_SCHEMA.KEY_COLUMN_USAGE The INFORMATION_SCHEMA.KEY_COLUMN_USAGE view details information about the columns used in a table’s indexes or constraints Listing 21-5 shows an output from DESCRIBE and a simple SELECT from the view 505x_Ch21_FINAL.qxd 6/27/05 3:41 PM Page 681 CHAPTER 21 ■ MYSQL DATA DICTIONARY Listing 21-5 INFORMATION_SCHEMA.KEY_COLUMN_USAGE mysql> DESCRIBE INFORMATION_SCHEMA.KEY_COLUMN_USAGE;... indicating whether the column can contain NULL values • INDEX_TYPE: Any of BTREE, RTREE, HASH, or FULLTEXT • COMMENT: Any comment used during creation of the index; otherwise blank The STATISTICS view has a wealth of information about the columns used in your indexes We’ll be using this table in the following examples to get a feel for the selectivity of your indexes, so stay tuned 683 505x_Ch21_FINAL.qxd... ROUTINE_COMMENT | varchar(64) | NO | | | | | DEFINER | varchar(77) | NO | | | | + + -+ + -+ -+ -+ 20 rows in set (0.01 sec) mysql> SELECT * FROM INFORMATION_SCHEMA.ROUTINES \G *************************** 1 row *************************** SPECIFIC_NAME: test_proc1 ROUTINE_CATALOG: NULL ROUTINE_SCHEMA: test ROUTINE_NAME: test_proc1 ROUTINE_TYPE: PROCEDURE 505x_Ch21_FINAL.qxd . later in this chapter for information about finding and reporting bugs to MySQL AB. For more information, refer to http://dev .mysql. com/doc /mysql/ en/gone-away.html and http://dev .mysql. com/doc /mysql/ en/communication-errors.html. Troubleshooting. and http://dev .mysql. com/doc /mysql/ en/communication-errors.html. Troubleshooting Start, Restart, and Shutdown Issues In this section, we’ll discuss common problems related to starting and shutting down the server properly, including the following: •Determining whether. run into trouble when installing or upgrading your server. See Chapter 14 for information that will help if you have problems installing or upgrading a MySQL database. CHAPTER 20 ■ TROUBLESHOOTING