Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống
1
/ 50 trang
THÔNG TIN TÀI LIỆU
Thông tin cơ bản
Định dạng
Số trang
50
Dung lượng
1,33 MB
Nội dung
Backups and Recovery 13
R1Soft is that it provides what it calls near-Continuous Online Backups. It does this by perform-
ing backups very frequently (every 15 minutes or less). This provides for a very small window of
time that data can be lost. In addition, the R1Soft software also provides for complete bare-metal
restore for MySQL servers.
The homepage of R1Soft is:
www.r1soft.com.
Copying Databases to Another Machine
You can copy the .frm, .MYI,and.MYD files for MyISAM tables and the .frm and data files
(
.ibd or ibdata) for InnoDB between different hardware architectures that support the same
floating-point format (Endianness). This means that you can transfer InnoDB and MyISAM
tables from Windows to Linux without doing a logical export and import. Simply shut down the
database (or lock the tables involved) and use
scp to copy the database. Or, restore a physical
backup to a different machine.
In cases where you need to transfer databases between different architectures, you can use
mysqldump to create a file containing SQL statements. You can then transfer the dump file to
the second machine (the destination host) and feed it as input to the
mysql client.
To move a database from one machine to another, run the following from the machine currently
holding the database (the target host):
shell> mysqldump databases sakila | mysql -h destination_host
sakila
For large tables, exporting a tab-delimited file and using mysqlimport is much faster than
using
mysqldump to export INSERT statements and restoring with source or the redirection
operator (
<). The tab=/path/to/backup option to mysqldump creates a tab-delimited
ASCII data file (
.txt) and schema file (.sql) for each table, when mysqldump is run locally.
First, create the backup directory and dump the database:
shell> mkdir /path/to/backup
shell> mysqldump tab=/path/to/backup databases sakila
Then copy the files in /path/to/backup directory to the destination machine and load the
files into
mysqld there:
shell> cat /path/to/backup/*.sql | mysql sakila
shell> mysqlimport sakila /path/to/destination/copy/*.txt
The grant tables (user permissions) are stored in the mysql database. If you do not
have a mysql database, mysqld may not start up on the new machine. Make sure to
FLUSH PRIVILEGES or restart mysqld when the grant tables are imported.
467
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Part III Core MySQL Administration
Recovering from Crashes
Many administrators spend a significant amount of time on backups and then do not spend time
on their recovery strategies. However, they make a serious mistake by not planning for how they
will recover or ever testing backups and the recovery process by performing a recovery.
The recovery process is going to vary depending on your objectives. It will always begin
with the restoration of a backup. With physical backups you just copy the files to the server
where the recovery is taking place and restart the server. For a logical backup the techniques
used for recovery are going to vary — recovery may consist of loading of files with the
source
command, redirecting files with the < operator, or using mysqlimport.
Often after the backup is restored you will need to restore the server to a point-in-time after the
last backup. If this is the case you need to perform what is called a point-in-time recovery.
You can perform a point-in-time recovery with any backup process because you are using incre-
mental backups (such as the binary log files) to bring the server up to a certain point-in-time
after restoring a previous backup.
MySQL server uses a binary format for the log files to save space. This means you cannot view
it directly. MySQL supplies a utility called
mysqlbinlog to convert these logs to a text format
that you can view. For more on binary logging, see Chapter 16.
The process for performing a point-in-time restore is as follows:
■ Restore the database using the last backup
■ Determine the first binary log and starting position needed
■ Determine the last binary log needed
■ Convert the binary log(s) to text format with the mysqlbinlog utility, using options to
specify the start and stop time
■ Import the converted binary log(s)
As with any recovery process, the first step is to restore the last backup performed. This restora-
tion will vary depending on how the backup was performed. For this example assume a file sys-
tem snapshot was performed at midnight of the 16th of September and the logs were flushed at
the same time. This means you have a physical backup and the restoration should just be copy-
ing the files to the server and starting up
mysqld again.
Once the basic restoration is complete it is time to restore the data changes since the backup
was performed.
468
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Backups and Recovery 13
Here is a listing of the binary log directory:
$ ls -lh mysql-bin*
-rw-rw 1 mysqlmysql 257M Sep 16 23:48 mysql-bin.010309
-rw-rw 1 mysqlmysql 257M Sep 17 00:02 mysql-bin.010310
-rw-rw 1 mysqlmysql 257M Sep 17 03:48 mysql-bin.010311
-rw-rw 1 mysqlmysql 257M Sep 17 19:01 mysql-bin.010312
-rw-rw 1 mysqlmysql 162M Sep 17 19:03 mysql-bin.010313
-rw-rw 1 mysqlmysql 8.3K Sep 17 19:01 mysql-bin.index
This means that mysql-bin.010310 is the first binary log created after the backup was per-
formed. This was determined by looking at the timestamp of the log files, which shows the last
time the log file was modified. Knowing the backup was performed at midnight you can see that
mysql-bin.010309 was the last log written before midnight. Therefore the next log file is the
one with which you want to start your restoration.
For this example, you need to restore the server through the last log listed, which is
mysql-bin.010313.
If you have a large number of binary logs (such as in this case) to convert it would probably be
beneficial to script this process. The command to convert an entire binary file will look similar
to this:
$ mysqlbinlog mysql-bin.010310 > mysql-bin.010310.sql
This would convert the mysql-bin.010310 logtotextformatandstoreitinthe
mysql-bin.010310.sql file. You will have to do this for each log file needed. The final
part of the process is the import of the log files into the database server:
$ mysql user=root pasword < mysql-bin.010310.sql
This would need to be done for each converted binary log. Once again, scripting might be
helpful.
To create text files from parts of binary logs using
mysqlbinlog, specify a starting place
with either
start-datetime=’YYYY-MM-DD’ or start-position=# and ending
place with either
stop-datetime=’YYYY-MM-DD’ or stop-position=#. To determine
the exact position to start or stop you have to examine the binary log contents. The problem is
that this can be a large file. To start you have to convert the log to text format:
$ mysqlbinlog mysql-bin.010312 > mysql-bin.010312.sql
469
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Part III Core MySQL Administration
Once you convert the log file you can view the text-format log with a text editor. With a binary
log of 162 MB in size this may be tricky. If you are looking to end at a specific time you can
specify a stopping time:
$ mysqlbinlog stop-datetime=’2008-09-17 18:42:48’ mysql-bin.010312
> mysql-bin.010312.sql
Once you have trimmed the file it becomes much easier to view with the tail command. Now
you will still have to potentially look through a number of entries because a busy database
server is going to be executing hundreds, if not thousands, of queries a second. Here are the last
25 lines after trimming:
$ tail -25 mysql-bin.010312.sql
use usersession/*!*/;
SET TIMESTAMP=1221702167/*!*/;
UPDATE XXXXX /*!*/;
# at 185118382
#080917 18:42:47 server id 16 end_log_pos 185118409 Xid =
9731310851
COMMIT/*!*/;
# at 185118409
#080917 18:42:47 server id 16 end_log_pos 185118473 Query
thread_id=1273437368 exec_time=1 error_code=0
SET TIMESTAMP=1221702167/*!*/;
BEGIN/*!*/;
# at 185118473
#080917 18:42:47 server id 16 end_log_pos 185118508 Rand
SET @@RAND_SEED1=700138339, @@RAND_SEED2=45664511/*!*/;
# at 185118508
#080917 18:42:47 server id 16 end_log_pos 185119173 Query
thread_id=1273437368 exec_time=1 error_code=0
use usersession/*!*/;
SET TIMESTAMP=1221702167/*!*/;
UPDATE XXXXX /*!*/;
# at 185119173
#080917 18:42:47 server id 16 end_log_pos 185119200 Xid =
9731310854
COMMIT/*!*/;
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
$
In this case you want to execute the first COMMIT statement and then stop. The line after the
COMMIT statement shows the log position. The log position is 185118473. Now you can create
your final text format file with exactly the right information:
470
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Backups and Recovery 13
$ mysqlbinlog stop-position=185118473 mysql-bin.010312 >
mysql-bin.010312.sql
This file (mysql-bin.010656.sql) is what you will want to import.
$ mysql user=root password < mysql-bin.010656.sql
It would be wise to examine the resulting file to ensure it is correct before execution of the log
file.
Table 13-6 lists common options for the
mysqlbinlog program.
TABLE 13-6
mysqlbinlog Options
Option Description
start-datetime=
"date_time"
Begins reading the binary log file at a timestamp equal to or
greater than the datetime argument.
stop-datetime=
"date_time"
Ends reading the binary log file at a timestamp equal to or
greater than the datetime argument.
start-position=
start_log_position
Begins reading the binary log file beginning at the first log
position equal to or greater than start_log_position.
stop-position=stop_
log_position
Ends reading the binary log file at the first event having a
log position equal to or greater than stop_log_position.
Planning for Disasters
Database recovery is part of the disaster planning process. What to do, who does it, and how
long the recovery process takes when things break requires thought, planning, and usually coor-
dination with other people and departments. It is important that you rehearse plans and perform
drills to make sure that the proper preparations are in place.
A backup plan and corresponding periodic restores of your backups should be part of the disas-
ter preparation. An incomplete list of issues covered could include:
■ Power
■ Employee termination process
■ Data center failover plan
■ Data retention strategies
471
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Part III Core MySQL Administration
A disaster plan should be written down and approved by everyone involved, including manage-
ment. It should include checklists and processes to carry out for various scenarios.
Summary
You have multiple methods of backing up your data, and depending on your situation, some
options are going to be better than others. Do not underestimate the importance of performing
backups and testing the recovery procedure. Ensure the backups and recovery processes are
actually working and current by testing frequently, preferably at least once per quarter. Other
periodic tasks may include a test of the backups and recovery processes, such as periodically
refreshing a QA server by recovering a production backup to it.
The following topics were covered in this chapter:
■ Backup and recovery terminology
■ Why backups are necessary
■ Backup methodology
■ The recovery process
■ Disaster planning
472
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
User Management
IN THIS CHAPTER
Learning about MySQL users
Managing user accounts
Resetting the root password
Debugging user account
problems
M
anaging the users for a MySQL server is one of the most impor-
tant tasks of a MySQL database administrator. Because of the
flexibility of the permissions system, it is not necessarily a trivial
task. There are many tips to help manage users.
Learning about MySQL Users
A user in MySQL is a combination of a username and host string.
A host string can be an IP address, hostname, fully qualified domain
name, or netmask. This means that even though they share a username,
admin@192.168.2.10 is different from admin@’192.168.2.%’,and
both users can have different passwords and permissions. In the following
example, we set up two users with the same username and different
passwords and permissions:
shell> mysql -u root -prootpass
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 8
Server version: 6.0.8-alpha-community MySQL Community Server (GPL)
Type ’help;’ or ’\h’ for help. Type ’\c’ to clear the buffer.
mysql> GRANT USAGE ON *.* TO admin@’192.168.2.10’
IDENTIFIED BY ’easytoguess’;
Query OK, 0 rows affected (0.22 sec)
mysql> GRANT ALL ON sakila.* TO admin@’192.168.2.20’
IDENTIFIED BY ’anotherpassword’;
473
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Part III Core MySQL Administration
Query OK, 0 rows affected (0.41 sec)
mysql> select user,host,password from mysql.user where user=’admin’;
+ + + +
| user | host | password |
+ + + +
| admin | 192.168.2.10 | *2F9A309FBEA7337E61AA2953EB48179BF9300B7C |
| admin | 192.168.2.20 | *4CBC947A0D5CF017233C027F4597C92A92D02F92 |
+ + + +
2 rows in set (0.05 sec)
mysql> exit
Bye
This allows for a flexible control system but can also cause confusion. How the server deter-
mines who a user is and what permissions are allowed for that user will be discussed in the next
section.
Access Control Lists
An ACL (Access Control List) is a list of permissions that is associated with an object. This list is
the basis for MySQL server’s security model and once you understand this it helps greatly when
troubleshooting problems with users not being able to connect.
MySQL keeps the ACLs (also called grant tables) cached in memory. When a user tries to
authenticate or run a command, MySQL checks the authentication information and permissions
against the ACLs, in a predetermined order. If you had two users,
admin@’192.168.2.%’
and then admin@192.168.2.10, the user admin@’192.168.2.%’ user comes before
admin@192.168.2.10 in the Access Control List. When MySQL checks authentication,
the
admin@’192.168.2.%’ user is the first user whose credentials match the credentials
provided. Remember how users with the same username but different host strings can have
different passwords? The following example shows what happens in this case; the computer used
by the user has an IP address of 192.168.2.20:
shell> mysql -u admin –peasytoguess –h 192.168.1.5
ERROR 1045 (28000): Access denied for user ’admin @’192.168.2.20’
(using password: YES)
What happened was the account attempted to connect using the account admin@192.168.
2.10
, which was configured with the password of easytoguesss. When attempting to connect
the server authenticated against the user account
admin@192.168.2.20, which has a password
of
anotherpassword.
If they had same passwords the connection would be allowed — but the connection may be
using an account with different privileges than expected. If you are not sure what user you are
actually logged in as you can use the
USER() and CURRENT_USER() functions to determine
how you are connected.
474
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
User Management 14
The USER() function shows which username and host the MySQL server sees the connection
as coming from. The
CURRENT_USER() function shows which username and host the con-
nection is actually authenticated. Note that the
SHOW GRANTS statement with no arguments
shows the privileges for the user the connection was authenticated — the privileges for the
CURRENT_USER().
Wildcards
Wildcard characters (% and _) are allowed in host strings. This is another source of confusion as
admin@192.168.2.10 is a completely different user than admin@’192.168.2.%’. As stated
above, MySQL checks the access control list in order. However, we did not reveal how the
MySQL server orders the access control list.
MySQL orders the access control list with the least specific hosts last. This means that hostnames
and IPs without wildcards or netmasks are placed before hostnames and IPs with wildcards and
netmasks. MySQL matches the most specific user and hostname.
In the following example, after deleting the users from the previous example,
admin@192.168.
2.10
is given full read/write permissions to the sakila database, and admin@’19.168.2.%’ is
given read-only permissions to the
sakila database:
mysql> DROP USER admin@192.168.2.20;
Query OK, 0 rows affected (0.01 sec)
mysql> DROP USER admin@192.168.2.10;
Query OK, 0 rows affected (0.01 sec)
mysql> SELECT USER, HOST, PASSWORD FROM MYSQL.USER WHERE
USER=’admin’;
Empty set (0.01 sec)
mysql> GRANT SELECT ON sakila.* TO admin@’1921.68.2.%’
identified by ’adminpass’;
Query OK, 0 rows affected (0.39 sec)
mysql> GRANT ALL ON sakila.* TO admin@’192.168.2.10’ identified by
’adminpass’;
Query OK, 0 rows affected (0.00 sec)
mysql> exit
Bye
shell> mysql -u admin
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 8
Server version: 6.0.8-alpha-community MySQL Community Server (GPL)
Type ’help;’ or ’\h’ for help. Type ’\c’ to clear the buffer.
475
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Part III Core MySQL Administration
mysql> SHOW GRANTS\G
*************************** 1. row ***************************
Grants for admin@192.168.2.10: GRANT USAGE ON *.* TO ’admin’@’192.
168.2.10’ IDENTIFIED BY PASSWORD ’*2C6396ADEEF1AF865672D48735
C0E3EC8B1A9CEC’
*************************** 2. row ***************************
Grants for admin@192.168.2.10: GRANT ALL PRIVILEGES ON `sakila`.*
TO ’admin’@’192.168.2.10’
2 rows in set (0.00 sec)
mysql> exit
Bye
The connection was authenticated as the user admin@192.168.2.10 because it has a
more specific host than the user
admin@’192.168.2.%’ and, therefore, appeared earlier
in MySQL’s access control list. This would only happen if the user connected from the IP
address 192.168.2.10. If they connected from 192.168.2.20, it would use the more general
host of
’192.168.2.%’. If they attempted to connect from 192.168.3.10, they would not be
authenticated.
System tables
All the user and permission information is stored in the mysql database in a set of tables known
as the grant tables. If you execute
’SHOW DATABASES’ on a typical default install of MySQL it
will look like the following:
mysql> SHOW DATABASES;
+ +
| Database |
+ +
| information_schema |
| mysql |
| test |
+ +
3 rows in set (0.02 sec)
The information_schema database really is not a database but an interface to various system
metadata (see Chapter 21 for more information about the
information_schema database).
The
test database is an empty database used for testing purposes and as mentioned the mysql
database stores the user information. In addition to the grant tables, the mysql database has
tables containing other system information. For example, a table called
event is used by the
476
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
[...]... /var/lib /mysql is the directory of the mysqld.sock file do the following: /home/kmurphy> ls -lh /var/lib drwxr-x - 5 mysqlmysql 4096 Sep 06 18:33 mysql This is the proper permissions, owned by the mysql user who is the user used to run the mysqld daemon If it is owned by the root user this would cause a problem: /home/kmurphy> ls -lh /var/lib drwxr-x - 5 root root 4096 Sep 06 18:33 mysql In this case, the root... Start the MySQL server with the init-file option It might look something like this: C:\> C:\Program Files \MySQL\ MySQL Server 5.1\bin\mysqld console init-file=C:\reset_pass.txt If you installed MySQL to another location adjust the directory accordingly The server executes the contents of the file named by the init-file option at startup while displaying any output to the console If you installed MySQL. .. connections to the MySQL server This minimizes the risk somewhat Here is the procedure: 1 Edit the configuration file and add the skip-grant-tables and (optionally) the bind-address option to the mysqld section 2 Restart the MySQL server Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark 487 14 Part III Core MySQL Administration 3 Connect to the mysqld server using the mysql client... from scratch Here is an example showing this: mysql> CREATE USER ’ops’@’192.168.%’ IDENTIFIED BY ’password’; Query OK, 0 rows affected (0.00 sec) mysql> GRANT ALL PRIVILEGES ON test.* TO ’ops’@’192.168.%’; Query OK, 0 rows affected (0.00 sec) mysql> DROP USER ’ops’@’192.168.%’; Query OK, 0 rows affected (0.00 sec) mysql> SELECT user,host,password FROM mysql. user; + + -+ -+... named /home/kmurphy /mysql- init The file contains the root user password Be certain that it cannot be read by other users Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark 489 14 Part III Core MySQL Administration Edit your /etc/my.cnf file Under [myqld] add init-file=/home/kmurphy/ mysql- init 3 Shut down the MySQL server in your normal manner 4 Start the MySQL server in your... has GRANT privileges and do the following: mysql> SET PASSWORD FOR ops@’192.168.%’ = PASSWORD(’New_Password’); Query OK, 0 rows affected (0.00 sec) And now the user can log in with the new password: shell> mysql -u ops -p Enter password: ************ Welcome to the MySQL monitor Commands end with ; or \g Your MySQL connection id is 8 Server version: 6.0.8-alpha MySQL Community Server (GPL) Type ’help;’... be specified If you also used the skip-networking option, you must run the mysql client from the server itself shell> mysql 4 Issue the following statements, replacing New_Password with the password that you want to update the root users to have mysql> UPDATE mysql. user SET Password=PASSWORD(’New_Password’) WHERE User=’root’; mysql> FLUSH PRIVILEGES; What happens here is that the UPDATE statement resets... + -+ -+ -+ 4 rows in set (0.00 sec) mysql> RENAME USER ’ops’@’192.168.%’ TO ’support’@’192.168.%’; ERROR 1396 (HY000): Operation RENAME USER failed for ’ops’@ ’192.168.%’ mysql> RENAME USER ’ops’@’192.168.%’ TO ’over_lords’@’192.168.%’; Query OK, 0 rows affected (0.00 sec) mysql> SELECT user,host,password FROM mysql. user; + + -+ + | user | host |... Management event scheduler (see Chapter 7 for more information about events) Because of new additions such as this, the tables in the mysql database vary from version to version Here are the tables in a server running mysqld 6.0.8-alpha: mysql> SHOW TABLES; + -+ | Tables_in _mysql | + -+ | backup_history | | backup_progress | | columns_priv | | db | | event | | func | | general_log | |... www.verypdf.com to remove this watermark 479 14 Part III Core MySQL Administration The RENAME USER command renames an existing account The RENAME COMMAND will return an error if the new user already exists mysql> CREATE USER ’ops’@’192.168.%’ IDENTIFIED BY ’password’; Query OK, 0 rows affected (0.00 sec) mysql> SELECT user,host,password FROM mysql. user; + + -+ -+ | user | host . ls -lh mysql- bin*
-rw-rw 1 mysql mysql 257M Sep 16 23:48 mysql- bin.010309
-rw-rw 1 mysql mysql 257M Sep 17 00:02 mysql- bin.010310
-rw-rw 1 mysql mysql 257M. 03:48 mysql- bin.010311
-rw-rw 1 mysql mysql 257M Sep 17 19:01 mysql- bin.010312
-rw-rw 1 mysql mysql 162M Sep 17 19:03 mysql- bin.010313
-rw-rw 1 mysql mysql