使用Xtrabackup备份MySQL数据库(续)
在上一篇里,演示了使用xtrabackup对InnoDB进行在线物理热备,使用innobackupex脚本,可以很简单的一条命令行搞定InnoDB和MyISAM的物理备份。
本文则演示如何从xtrabackup的备份中进行恢复。本次恢复的是一个600GB大小的InnoDB数据库,备份的时候没有使用gzip压缩。
首先将备份好的tar文件解开到目标数据库的数据路径下,这一步类似oracle的restore database:
tar -ixvf mysqlbak.tar
注意解出来的文件和目录的属主以及权限是否正确。如果是将备份恢复到一台全新的环境,则需要修改/etc/my.cnf,将innodb_data_file_path等参数设置和原备份的库一致。然后执行:
$innobackupex-1.5.1 --apply-log /opt/mysqldata
这一步类似于oracle的recover database,从日志来看,差不多一个小时执行完毕,该InnoDB数据库分配空间600GB,实际使用空间约590GB,并且数据的更新量还是比较大的,大约一个小时apply-log完成。运行的日志简单记录如下:
InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy.
All Rights Reserved.
This software is published under
the GNU GENERAL PUBLIC LICENSE Version 2, June 1991.
IMPORTANT: Please check that the apply-log run completes successfully.
At the end of a successful apply-log run innobackup
prints "innobackup completed OK!".
090708 09:50:44 innobackupex: Starting ibbackup with command:
xtrabackup --prepare --target-dir=/opt/mysqldata
xtrabackup Ver rc-0.7 for 5.0.77 unknown-linux-gnu (x86_64)
xtrabackup: cd to /opt/mysqldata
xtrabackup: This target seems to be not prepared yet.
xtrabackup: xtrabackup_logfile detected: size=2882535424, start_lsn=(514 2288109039)
xtrabackup: Temporary instance for recovery is set as followings.
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:10000M;ibdata2:10000M;ibdata3:10000M...;ibdata60:10000M
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 1
xtrabackup: innodb_log_file_size = 2882535424
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
InnoDB: Log scan progressed past the checkpoint lsn 514 2288109039
090708 9:50:45 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Doing recovery: scanned up to log sequence number 514 2293351424 (0 %)
InnoDB: Doing recovery: scanned up to log sequence number 514 2298594304 (0 %)
InnoDB: Doing recovery: scanned up to log sequence number 514 2303837184 (0 %)
InnoDB: Doing recovery: scanned up to log sequence number 514 2309080064 (0 %)
090708 9:50:47 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50
51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75
76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: Doing recovery: scanned up to log sequence number 514 2314322944 (1 %)
InnoDB: Doing recovery: scanned up to log sequence number 514 2319565824 (1 %)
InnoDB: Doing recovery: scanned up to log sequence number 514 2324808704 (1 %)
InnoDB: Doing recovery: scanned up to log sequence number 514 2330051584 (1 %)
InnoDB: Doing recovery: scanned up to log sequence number 514 2335294464 (1 %)
...这里省略若干行
InnoDB: Doing recovery: scanned up to log sequence number 514 3881944064 (62 %)
InnoDB: Doing recovery: scanned up to log sequence number 514 3887186944 (62 %)
InnoDB: Doing recovery: scanned up to log sequence number 514 3887732530 (62 %)
090708 10:52:00 InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percents: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50
51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75
76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
InnoDB: Apply batch completed
InnoDB: In a MySQL replication slave the last master binlog file
InnoDB: position 0 350504077, file name mysql-bin.000748
InnoDB: Last MySQL binlog file position 0 36434864, file name /opt/mysqllog/mysql-bin.003015
090708 10:52:17 InnoDB: Started; log sequence number 514 3887732530
[notice (again)]
If you use binary log and don't use any hack of group commit,
the binary log position seems to be:
InnoDB: Last MySQL binlog file position 0 36434864, file name /opt/mysqllog/mysql-bin.003015
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
090708 10:52:17 InnoDB: Starting shutdown...
090708 10:52:24 InnoDB: Shutdown completed; log sequence number 514 3887732530
090708 10:52:24 innobackupex: Restarting xtrabackup with command:
xtrabackup --prepare --target-dir=/opt/mysqldata
for creating ib_logfile*
xtrabackup Ver rc-0.7 for 5.0.77 unknown-linux-gnu (x86_64)
xtrabackup: cd to /opt/mysqldata
xtrabackup: This target seems to be already prepared.
xtrabackup: notice: xtrabackup_logfile was already used to '--prepare'.
xtrabackup: Temporary instance for recovery is set as followings.
xtrabackup: innodb_data_home_dir = ./
xtrabackup: innodb_data_file_path = ibdata1:10000M;ibdata2:10000M;ibdata3:10000M;...;ibdata60:10000M
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 4
xtrabackup: innodb_log_file_size = 104857600
xtrabackup: Starting InnoDB instance for recovery.
xtrabackup: Using 104857600 bytes for buffer pool (set by --use-memory parameter)
090708 10:52:25 InnoDB: Log file ./ib_logfile0 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile0 size to 100 MB
InnoDB: Database physically writes the file full: wait...
InnoDB: Progress in MB: 100
090708 10:52:25 InnoDB: Log file ./ib_logfile1 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile1 size to 100 MB
InnoDB: Database physically writes the file full: wait...
InnoDB: Progress in MB: 100
090708 10:52:26 InnoDB: Log file ./ib_logfile2 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile2 size to 100 MB
InnoDB: Database physically writes the file full: wait...
InnoDB: Progress in MB: 100
090708 10:52:26 InnoDB: Log file ./ib_logfile3 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile3 size to 100 MB
InnoDB: Database physically writes the file full: wait...
InnoDB: Progress in MB: 100
InnoDB: The log sequence number in ibdata files does not match
InnoDB: the log sequence number in the ib_logfiles!
090708 10:52:27 InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: In a MySQL replication slave the last master binlog file
InnoDB: position 0 350504077, file name mysql-bin.000748
InnoDB: Last MySQL binlog file position 0 36434864, file name /opt/mysqllog/mysql-bin.003015
090708 10:52:27 InnoDB: Started; log sequence number 514 3887732748
[notice (again)]
If you use binary log and don't use any hack of group commit,
the binary log position seems to be:
InnoDB: Last MySQL binlog file position 0 36434864, file name /opt/mysqllog/mysql-bin.003015
xtrabackup: starting shutdown with innodb_fast_shutdown = 1
090708 10:52:27 InnoDB: Starting shutdown...
090708 10:52:29 InnoDB: Shutdown completed; log sequence number 514 3887732748
090708 10:52:29 innobackupex: innobackup completed OK!
运行完毕后,启动mysql即可。
使用Xtrabackup备份MySQL数据库
MySQL数据库的备份,一直是个比较头痛的问题。各种工具虽然不少,但一个真正好用易用的,却又非常难找。Mysqldump做为数据的逻辑备份工具还行,但是无法进行在线热备,而没有物理备份工具,在数据量比较大的时候,恢复的时间也会长得无法接受。InnoDB倒是有个商业的InnoDB Hotbackup,可以对InnoDB引擎的表实现在线热备。最近发现了一个工具,percona出品的Xtrabackup,是InnoDB Hotbackup的一个开源替代品,可以在线对InnoDB/XtraDB引擎的表进行物理备份,试用了一下,非常的不错,值得向MySQL DBA们推荐。
下面是一个实际备份的例子,采用了gzip将备份流进行压缩,约20GB的数据库,压缩后大小为340MB,当然,压缩后的大小跟数据库中实际使用的空间是相关的。备份时间约6分44秒。
innobackupex是参考了InnoDB Hotbackup的innoback脚本修改而来的,主要是为了方便的同时备份InnoDB和MyISAM引擎的表,并且加入了一些使用的选项。如–slave-info可以记录备份恢复后,作为slave需要的一些信息,根据这些信息,可以很方便的利用备份来重做slave。
注意,从备份后的tar包解包的时候,需要使用-i参数。最新发布的是0.7版,猛击这里下载
MySQL DBA们,你是如何做备份的呢?欢迎到这里探讨。
$innobackupex-1.5.1 --user=root --stream=tar /bak/ --slave-info | gzip > /bak/bak_mysql.tar.gz
InnoDB Backup Utility v1.5.1-xtrabackup; Copyright 2003, 2009 Innobase Oy.
All Rights Reserved.
This software is published under
the GNU GENERAL PUBLIC LICENSE Version 2, June 1991.
IMPORTANT: Please check that the backup run completes successfully.
At the end of a successful backup run innobackup
prints "innobackup completed OK!".
innobackupex: Using mysql Ver 14.12 Distrib 5.0.67, for redhat-linux-gnu (x86_64)
using EditLine wrapper
innobackupex: Using mysql server version 5.0.67-log
innobackupex: Created backup directory /bak
090625 15:23:00 innobackupex: Starting mysql with options: --unbuffered --user=root
090625 15:23:00 innobackupex: Connected to database with mysql child process (pid=3431)
090625 15:23:04 innobackupex: Connection to database server closed
090625 15:23:04 innobackupex: Starting ibbackup with command:
xtrabackup --backup --suspend-at-end --log-stream --target-dir=./
innobackupex: Waiting for ibbackup (pid=3565) to suspend
innobackupex: Suspend file '/opt/mysqldata/xtrabackup_suspended'
xtrabackup: suspend-at-end is enabled.
xtrabackup: uses posix_fadvise().
xtrabackup: cd to /opt/mysqldata
xtrabackup: Target instance is assumed as followings.
xtrabackup: innodb_data_home_dir = /opt/mysqldata
xtrabackup: innodb_data_file_path = ibdata1:10G;ibdata2:10G
xtrabackup: innodb_log_group_home_dir = ./
xtrabackup: innodb_log_files_in_group = 4
xtrabackup: innodb_log_file_size = 104857600
xtrabackup: use O_DIRECT
xtrabackup: Stream mode.
>> log scanned up to (0 3053406941)
090625 15:23:06 innobackupex: Continuing after ibbackup has suspended
innobackupex: Starting to backup InnoDB tables and indexes
innobackupex: from original InnoDB data directory '/opt/mysqldata'
innobackupex: Backing up as tar stream 'ibdata1'
>> log scanned up to (0 3053416714)
...这里省略若干行
>> log scanned up to (0 3054123851)
tar: ibdata1: file changed as we read it
innobackupex: Backing up as tar stream 'ibdata2'
>> log scanned up to (0 3054142116)
...这里省略若干行
>> log scanned up to (0 3054618483)
innobackupex: Backing up file '/opt/mysqldata/test/sp.ibd'
innobackupex: Backing up file '/opt/mysqldata/test/tmp_dy.ibd'
innobackupex: Backing up files '/opt/mysqldata/testdb/*.ibd' (206 files)
>> log scanned up to (0 3054638401)
>> log scanned up to (0 3054668860)
tar: testdb/group_group_thread_0027.ibd: file changed as we read it
>> log scanned up to (0 3054695015)
>> log scanned up to (0 3054928216)
tar: testdb/group_thread_reply_0007.ibd: file changed as we read it
>> log scanned up to (0 3054952588)
>> log scanned up to (0 3055005439)
tar: testdb/group_user_0001.ibd: file changed as we read it
>> log scanned up to (0 3055028610)
>> log scanned up to (0 3055044650)
tar: testdb/group_user_0006.ibd: file changed as we read it
>> log scanned up to (0 3055060461)
innobackupex: Backing up file '/opt/mysqldata/testdb/comments.ibd'
innobackupex: Backing up file '/opt/mysqldata/testdb/testdb.ibd'
innobackupex: Backing up file '/opt/mysqldata/testdb/testdb_content.ibd'
innobackupex: Backing up file '/opt/mysqldata/testdb/testdb_ids.ibd'
090625 15:29:17 innobackupex: Starting mysql with options: --unbuffered --user=root
090625 15:29:17 innobackupex: Connected to database with mysql child process (pid=5458)
>> log scanned up to (0 3055072495)
090625 15:29:21 innobackupex: Starting to lock all tables...
>> log scanned up to (0 3055087148)
>> log scanned up to (0 3055119993)
090625 15:29:39 innobackupex: All tables locked and flushed to disk
090625 15:29:39 innobackupex: Starting to backup .frm, .MRG, .MYD, .MYI,
innobackupex: .TRG, .TRN, and .opt files in
innobackupex: subdirectories of '/opt/mysqldata'
innobackupex: Backing up file '/opt/mysqldata/test/sp.frm'
innobackupex: Backing up file '/opt/mysqldata/test/tmp_dy.frm'
innobackupex: Backing up files '/opt/mysqldata/testdb/*.{frm,MYD,MYI,MRG,TRG,TRN,opt}' (207 files)
innobackupex: Backing up file '/opt/mysqldata/testdb/comments.frm'
innobackupex: Backing up file '/opt/mysqldata/testdb/testdb.frm'
innobackupex: Backing up file '/opt/mysqldata/testdb/testdb_content.frm'
innobackupex: Backing up file '/opt/mysqldata/testdb/testdb_ids.frm'
innobackupex: Backing up file '/opt/mysqldata/testdb/db.opt'
innobackupex: Backing up files '/opt/mysqldata/mysql/*.{frm,MYD,MYI,MRG,TRG,TRN,opt}' (52 files)
090625 15:29:40 innobackupex: Finished backing up .frm, .MRG, .MYD, .MYI, .TRG, .TRN, and .opt files
innobackupex: Resuming ibbackup
xtrabackup: The latest check point (for incremental): '0:3054881736'
>> log scanned up to (0 3055120013)
xtrabackup: Transaction log of lsn (0 3053102766) to (0 3055120013) was copied.
090625 15:29:44 innobackupex: All tables unlocked
090625 15:29:44 innobackupex: Connection to database server closed
innobackupex: Backup created in directory '/bak/'
innobackupex: MySQL binlog position: filename '', position
innobackupex: MySQL slave binlog position: master host '127.0.0.1',
filename 'mysql-bin.000006', position 227207755
090625 15:29:44 innobackupex: innobackup completed OK!
innobackupex: You must use -i (--ignore-zeros) option for extraction of the tar stream.
在同一台主机配置MySQL Cluster
MySQL cluster是share nothing的集群,采用ndb存储引擎,和Oracle的RAC采用集中存储不同,是一种分布式的架构,所以可以很轻松的实现在同一台主机上配置MySQL Cluster,相对RAC来说要简单得多。
在MySQL Cluster中,有三种不同的节点:
- 管理节点:守护进程为ndb_mgmd,用于管理cluster。
- 数据节点: 守护进程为ndbd,用于存放数据
- SQL节点:守护进程为mysqld,就是一个MySQL实例,对外供客户端连接访问数据。
本文将在一台64位linux主机上同时配置上述三种节点。在实际生产环境中,根据需要,可以在相同或者不同的机器部署节点。本次实例中共包含以下节点:
- 一个管理节点
- 两个数据节点
- 三个SQL节点
下载Mysql cluster,当前版本7.0.6,http://dev.mysql.com/downloads/cluster/7.0.html
解压,并复制到安装目录
tar zxvf mysql-cluster-gpl-7.0.6-linux-x86_64-glibc23.tar.gz cp mysql-cluster-gpl-7.0.6-linux-x86_64-glibc23 /u01/mysql-cluster cd /u01/mysql-cluster
创建三个MySQL实例的数据目录
mkdir data/data1 mkdir data/data2 mkdir data/data3 mkdir data/data1/mysql mkdir data/data1/test mkdir data/data2/mysql mkdir data/data2/test mkdir data/data3/mysql mkdir data/data3/test
Cluster配置文件如下
$ more conf/config.ini [ndbd default] noofreplicas=2 [ndbd] hostname=localhost id=2 [ndbd] hostname=localhost id=3 [ndb_mgmd] id = 1 hostname=localhost [mysqld] id=4 hostname=localhost [mysqld] id=5 hostname=localhost [mysqld] id=6 hostname=localhost
三个MySQL实例配置文件如下
$ more conf/my1.cnf [mysqld] ndb-nodeid=4 ndbcluster=true datadir=/u01/mysql-cluster/data/data1 basedir=/u01/mysql-cluster port=9306 server-id=1 log-bin $ more conf/my2.cnf [mysqld] ndb-nodeid=5 ndbcluster=true datadir=/u01/mysql-cluster/data/data2 basedir=/u01/mysql-cluster port=9307 server-id=2 log-bin $ more conf/my3.cnf [mysqld] ndb-nodeid=6 ndbcluster=true datadir=/u01/mysql-cluster/data/data3 basedir=/u01/mysql-cluster port=9308 server-id=3 log-bin
初始化三个MySQL实例
script/mysql_install_db --basedir=/u01/mysql-cluster --datadir=/u01/mysql-cluster/data/data1 script/mysql_install_db --basedir=/u01/mysql-cluster --datadir=/u01/mysql-cluster/data/data2 script/mysql_install_db --basedir=/u01/mysql-cluster --datadir=/u01/mysql-cluster/data/data3
初始化管理节点
bin/ndb_mgmd --initial -f conf/config.ini --configdir=/u01/mysql-cluster
进入管理节点查看配置
$ bin/ndb_mgm -- NDB Cluster -- Management Client -- ndb_mgm> help --------------------------------------------------------------------------- NDB Cluster -- Management Client -- Help --------------------------------------------------------------------------- HELP Print help text HELP COMMAND Print detailed help for COMMAND(e.g. SHOW) SHOW Print information about cluster CREATE NODEGROUP, ... Add a Nodegroup containing nodes DROP NODEGROUP Drop nodegroup with id NG START BACKUP [NOWAIT | WAIT STARTED | WAIT COMPLETED] START BACKUP [ ] [NOWAIT | WAIT STARTED | WAIT COMPLETED] START BACKUP [ ] [SNAPSHOTSTART | SNAPSHOTEND] [NOWAIT | WAIT STARTED | WAIT COMPLETED] Start backup (default WAIT COMPLETED,SNAPSHOTEND) ABORT BACKUP Abort backup SHUTDOWN Shutdown all processes in cluster CLUSTERLOG ON [ ] ... Enable Clus = ALERT | CRITICAL | ERROR | WARNING | INFO | DEBUG = STARTUP | SHUTDOWN | STATISTICS | CHECKPOINT | NODERESTART | CONNECTION | INFO | ERROR | CONGESTION | DEBUG | BACKUP = 0 - 15 = ALL | Any database node id For detailed help on COMMAND, use HELP COMMAND. ndb_mgm> show Connected to Management Server at: localhost:1186 Cluster Configuration --------------------- [ndbd(NDB)] 2 node(s) id=2 (not connected, accepting connect from localhost) id=3 (not connected, accepting connect from localhost) [ndb_mgmd(MGM)] 1 node(s) id=1 @localhost (mysql-5.1.34 ndb-7.0.6) [mysqld(API)] 3 node(s) id=4 (not connected, accepting connect from localhost) id=5 (not connected, accepting connect from localhost) id=6 (not connected, accepting connect from localhost)
初始化数据节点
bin/ndbd --initial -c localhost:1186 2009-06-21 23:13:19 [ndbd] INFO -- Configuration fetched from 'localhost:1186', generation: 1 bin/ndbd --initial -c localhost:1186 2009-06-21 23:13:50 [ndbd] INFO -- Configuration fetched from 'localhost:1186', generation: 1
启动SQL节点
bin/mysqld --defaults-file=conf/my1.cnf& [1] 17843 090621 23:14:36 [Warning] No argument was provided to --log-bin, and --log-bin-index was not used; so replication may break when this MySQL server acts as a master and has his hostname changed!! Please use '--log-bin=test-bin' to avoid this problem. InnoDB: The first specified data file ./ibdata1 did not exist: InnoDB: a new database to be created! 090621 23:14:36 InnoDB: Setting file ./ibdata1 size to 10 MB InnoDB: Database physically writes the file full: wait... 090621 23:14:36 InnoDB: Log file ./ib_logfile0 did not exist: new to be created InnoDB: Setting log file ./ib_logfile0 size to 5 MB InnoDB: Database physically writes the file full: wait... 090621 23:14:36 InnoDB: Log file ./ib_logfile1 did not exist: new to be created InnoDB: Setting log file ./ib_logfile1 size to 5 MB InnoDB: Database physically writes the file full: wait... InnoDB: Doublewrite buffer not found: creating new InnoDB: Doublewrite buffer created InnoDB: Creating foreign key constraint system tables InnoDB: Foreign key constraint system tables created 090621 23:14:36 InnoDB: Started; log sequence number 0 0 090621 23:14:36 [Note] NDB: NodeID is 4, management server 'localhost:1186' 090621 23:14:37 [Note] NDB[0]: NodeID: 4, all storage nodes connected 090621 23:14:37 [Note] Starting Cluster Binlog Thread 090621 23:14:37 [Note] Event Scheduler: Loaded 0 events 090621 23:14:37 [Note] bin/mysqld: ready for connections. Version: '5.1.34-ndb-7.0.6-cluster-gpl-log' socket: '/tmp/mysql.sock' port: 9306 MySQL Cluster Server (GPL) 090621 23:14:38 [Note] NDB Binlog: Ndb tables initially read only. 090621 23:14:38 [Note] NDB: Creating mysql.ndb_schema 090621 23:14:38 [Note] NDB Binlog: CREATE TABLE Event: REPL$mysql/ndb_schema 090621 23:14:38 [Note] NDB Binlog: logging ./mysql/ndb_schema (UPDATED,USE_WRITE) 090621 23:14:38 [Note] NDB: Creating mysql.ndb_apply_status 090621 23:14:39 [Note] NDB Binlog: CREATE TABLE Event: REPL$mysql/ndb_apply_status 090621 23:14:39 [Note] NDB Binlog: logging ./mysql/ndb_apply_status (UPDATED,USE_WRITE) 2009-06-21 23:14:39 [NdbApi] INFO -- Flushing incomplete GCI:s < 20/3 2009-06-21 23:14:39 [NdbApi] INFO -- Flushing incomplete GCI:s < 20/3 090621 23:14:39 [Note] NDB Binlog: starting log at epoch 20/3 090621 23:14:39 [Note] NDB Binlog: ndb tables writable
bin/mysqld --defaults-file=conf/my2.cnf& bin/mysqld --defaults-file=conf/my3.cnf&
查看cluster
bin/ndb_mgm -- NDB Cluster -- Management Client -- ndb_mgm> show Connected to Management Server at: localhost:1186 Cluster Configuration --------------------- [ndbd(NDB)] 2 node(s) id=2 @127.0.0.1 (mysql-5.1.34 ndb-7.0.6, Nodegroup: 0, Master) id=3 @127.0.0.1 (mysql-5.1.34 ndb-7.0.6, Nodegroup: 0) [ndb_mgmd(MGM)] 1 node(s) id=1 @127.0.0.1 (mysql-5.1.34 ndb-7.0.6) [mysqld(API)] 3 node(s) id=4 @127.0.0.1 (mysql-5.1.34 ndb-7.0.6) id=5 @127.0.0.1 (mysql-5.1.34 ndb-7.0.6) id=6 @127.0.0.1 (mysql-5.1.34 ndb-7.0.6)
创建测试表
bin/mysql -uroot -h localhost -P 9306 --socket=/tmp/mysql.sock Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 2 Server version: 5.1.34-ndb-7.0.6-cluster-gpl-log MySQL Cluster Server (GPL) Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. root@(none) 11:21:24>use test Database changed root@test 11:21:26>create table test_ndb(i int,a varchar(20),primary key(i)) engine=ndb; 090621 23:22:32 [Note] NDB Binlog: CREATE TABLE Event: REPL$test/test_ndb 090621 23:22:32 [Note] NDB Binlog: logging ./test/test_ndb (UPDATED,USE_WRITE) 090621 23:22:32 [Note] NDB Binlog: DISCOVER TABLE Event: REPL$test/test_ndb 090621 23:22:32 [Note] NDB Binlog: DISCOVER TABLE Event: REPL$test/test_ndb 090621 23:22:32 [Note] NDB Binlog: logging ./test/test_ndb (UPDATED,USE_WRITE) 090621 23:22:32 [Note] NDB Binlog: logging ./test/test_ndb (UPDATED,USE_WRITE) Query OK, 0 rows affected (1.10 sec) root@test 11:22:32>insert into test_ndb values(1,'NinGoo'); Query OK, 1 row affected (0.02 sec) [mysql@dbconsole mysql-cluster]$ ls -l data/data1/test total 12 -rw-rw---- 1 mysql dba 8578 Jun 21 23:22 test_ndb.frm -rw-rw---- 1 mysql dba 0 Jun 21 23:22 test_ndb.ndb [mysql@dbconsole mysql-cluster]$ ls -l data/data2/test total 12 -rw-rw---- 1 mysql dba 8578 Jun 21 23:22 test_ndb.frm -rw-rw---- 1 mysql dba 0 Jun 21 23:22 test_ndb.ndb [mysql@dbconsole mysql-cluster]$ ls -l data/data3/test total 12 -rw-rw---- 1 mysql dba 8578 Jun 21 23:22 test_ndb.frm -rw-rw---- 1 mysql dba 0 Jun 21 23:22 test_ndb.ndb $ bin/mysql -uroot -P 9307 --socket=/tmp/mysql.sock Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 3 Server version: 5.1.34-ndb-7.0.6-cluster-gpl-log MySQL Cluster Server (GPL) Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. root@(none) 11:24:38>use test Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Database changed root@test 11:24:41>select * from test_ndb; +---+--------+ | i | a | +---+--------+ | 1 | NinGoo | +---+--------+ 1 row in set (0.02 sec)
MySQL还能走多远?
MySQL最近这一年多可谓命途多舛。先是被日薄西山的Sun收购,又随Sun一起嫁入Oracle。因此不少人开始担忧起MySQL的前途来。其实这是大可不必的,一个产品的生命力,在于客户和市场。只要客户和市场认可了,不怕没有人挤破头来发展。
Oracle虽然在市场上称王,但论数据库的普及程度,估计接触过MySQL的人还是要更多一些,LAMP大名,早已名声在外。只是大部分接触MySQL的人,大多只是将MySQL做为一个简单的数据盒子,并没有能更深入的研究。这也跟应用场景有关。MySQL在之前大多只是在一些小应用中小打小闹,在真正的企业级市场,基本没他什么事。
但互联网企业这几年的逐渐红火,这种情况开始改变。一个成功的网站,系统所面临的压力,在一些传统行业是很难想像的。而大多数网站在初创时,基于技术和资金等多方面的考虑,往往都乐于选择开源的MySQL做为数据库解决方案。随着网站业务的发展,压力成指数倍的增加,MySQL数据库的架构设计便便的非常重要,公司也会愿意投入大量的人力资源去深入的研究MySQL。这就形成了一个良性的循环。
MySQL随着web2.0一起红火,MySQL DBA的职位也开始变得吃香。然而MySQL DBA人才的相对匮乏,也将可能成为制约MySQL发展的一道坎。好在国内这几年不断有一些优秀的MySQL DBA开始展露头角。比如阿里巴巴的小伙子简朝阳,毕业不过短短三年,从Oracle转向MySQL的时间更短,却能潜心研究,最近正式出版的新书《MySQL性能调优与架构设计》,可以说是填补国内关于MySQL架构类数据的空白。相信对于MySQL的普及推广,一定能起到积极的作用。
是的,不用怀疑。MySQL一定能走很远。MySQL DBA一定大有可为。正是相信这一点,我在前几天注册了一个域名:http://mysqldba.net,并用discuz!搭建了一个论坛,希望MySQL DBA们能够多多交流,共同进步。希望以后招聘MySQL DBA,不至于一年也难招到一位合适的了,呵呵。
