MySQL database standardization design

It is a good idea to establish a database table maintenance specification on a regular basis, instead of checking the database table until the problem arises. Taking into account the creation of a schedule for preventive maintenance to assist with automatic problems, you can take measures to correct: Execute regular database backup and Allow Log updates. Schedule regular table checks. Checklist

It is a good idea to establish a database table maintenance specification on a regular basis, instead of checking the database table until the problem arises. Taking into account the creation of a schedule for preventive maintenance to assist with automatic problems, you can take measures to correct: Execute regular database backup and Allow Log updates. Schedule regular table checks. Checklist

Create a database table maintenance Specification

It is a good idea to perform a database table check on a regular basis rather than when a problem occurs. Taking into account the establishment of a schedule for preventive maintenance to assist with automatic problems, you can take measures to correct them:

Perform regular database backup and Allow Log updates.

Schedule regular table checks. Using the checklist will reduce the chances of using backup. This job is easy to implement by using scheduled tasks in Windows and cron jobs in Unix (usually called from the crontab file of this account as shown in the running server.

For example, if you run the server as a mysql user, you can create a regular check from the mysql crontab file. If you do not know how to use cron, use the following command to view the relevant Unix manual page:

$ Man cron

$ Man crontab

The database table is checked during system boot before the server is started. And it may be restarted due to an early crash. If this is the case, the database table may have been destroyed and should be thoroughly checked.

Create a script for regular maintenance

To run an automatic table check, you can write a script to change the directory to the server data directory and perform myisamchk and isamchk on all database tables. If you only have a MyISAM table or an ISAM table, you only need one program. You can comment out the unrelated program from the script.

This tutorial can be called by cron or during system startup.

For maintenance purposes, you can use myisamchk-s to check the table. The-s, -- silent option enables myisamchk and isamchk to run in silent mode. Only messages are printed when an error occurs. In addition, myisamchk supports the -- fast option, which allows the program to skip people and tables that have not been modified since the last check.

1. A simple script

For example, a simple script that is easy to understand checks all tables in the Server Directory (DATADIR should be changed to the appropriate value for your system ):

#! /Bin/sh

Cd DATADIR

Myisamchk -- silent -- fast */*. MYIi

Samchk -- silent */*. ISM

2. A complicated script

A potential problem with this script: if there are many tables, the wildcard mode '*/*. myi' and '*/*. ISM 'may be unavailable because "too has arguments (too many parameters)" or the command line exceeds the length allowed by shell. The script can be further modified to (similarly, DATADIR is modified to a value suitable for your system ):

#! /Bin/sh

Datadir = DATADIR

Find $ dtatdir-name "*. MYI"-print | xargs myisamchk -- silent -- fast

Find $ dtatdir-name "*. ISM"-print | xargs isamchk -- silent

You can also specify multiple database directories in the script.

3. How to execute the script

If you save the script as check_tables, make sure it is executable. Of course, we recommend that you switch to the dedicated mysql instance first:

$ Su mysql

$ Vi check_tables (edit the script, you can also use your favorite editor)

$ Chmod + x check_tables

Run the command manually to check whether your script has an error:

$ Check_tables

Ideally, no results are output. If the system does not support External Locking, the visitor's server will change it during your checklist. In this case, the script may report the tables that are not actually correct. If the system supports External Locking, this problem will not occur.

Regular cron checklist in unix

The following describes how to create a script to run through cron and during system startup. In the example in this section, I assume that the script is installed in/usr/local/mysql/bin. You need to modify this process to check the tables in the data directory of each server. You can use different check_tables copies, or modify it to accept a command line parameter that specifies the data directory to be checked.

Assume that the mysql user calls the script check_tables from the crontab file.

1. Register with the user's identity first

$ Su mysql

2. Generate a temporary file to capture the scheduled task

$ Crontab-l>/tmp/entries

3. Add content in the last line of the generated file

Add the row 0 0 ** 0/usr/local/mysql/bin/check_tables to the last row of the temporary file:

$ Echo "0 0 ** 0/usr/local/mysql/bin/check_tables">/tmp/entries

It tells cron to run this option at 0 o'clock every Sunday. You can change the time or schedule as required. For the format of these options, see the crontab manual page.

4. Reschedule

$ Crontab/tmp/entries

If there is any information after the check, the cron job usually generates an email message to the user. Because the -- silent option is used, only when there is an error in the table, there will be output and mail information, so there will be no large amount of useless mail information. (You should understand now that the reason why the script uses the -- silent option for such regular maintenance is that your server should support External Locking, so that there will be no access conflict in the checklist. If you cannot do this, You 'd better maintain it when no user is using the server, for example, early morning.

Checklist during system startup

If you are using a BSD system, such as OpenBSD and FreeBSD, And you have added the server startup command to/etc/rc. local: to check the table during startup, you can call check_tables from the corresponding file before starting the server.

For systems that use the Sytem V-style startup method, for example, most commercial Unix systems, the startup method is from/etc/rc. one of the d directories calls mysql. server script, the checklist process is complicated before the database starts, because the scripts in these directories must understand the start and stop parameters.

For example, write a script like this and name it mysql. check. When the parameter is set to start, check_tables is called. When the parameter is set to stop, nothing is done:

#! /Bin/sh

# See hou we sere called

Case "$1" in

Start)

Echo-n "Checking MySQL tables :"

If [-x/usr/local/mysql/bin/check_tables]; then

/Usr/local/mysql/bin/check_tables

Fi ;;

Stop)

# Don't do anything

;;

*)

Echo "Usage: $ o {start | stop }"

Exit 1

Esac

Exit 0

Now you can install mysql. check. This process class seems to be introduced in chapter 2 to allow the server to automatically start the installation of mysql. server process. You must give mysql. check a lower prefix in the running directory to run mysql. server. For example, if you use S99mysql. server to connect to mysql. server in the running directory, you should use S98mysql. check to link to mysql. check.

Because Linux has the advantages of BSD and Sytem V systems, the above two methods are fully applicable to Linux. For convenience, the first method is generally used.