]]>
In many cases, binaries can no longer dump core after calling setuid().
Under Linux it is possible to re-enable this with a system call.
e.g.
+#ifdef __linux__
+#include <sys/prctl.h>
+#endif
+
#ifdef HAVE_purify
#define IF_PURIFY(A,B) (A)
#else
@@ -1362,6 +1366,10 @@
sql_perror("setuid");
unireg_abort(1);
}
+#ifdef __linux__
+ /* inform kernel that process is dumpable */
+ prctl(PR_SET_DUMPABLE,1,0,0,0);
+#endif /* __linux__ */
#endif
+#include <sys/prctl.h>
+#endif
+
#ifdef HAVE_purify
#define IF_PURIFY(A,B) (A)
#else
@@ -1362,6 +1366,10 @@
sql_perror("setuid");
unireg_abort(1);
}
+#ifdef __linux__
+ /* inform kernel that process is dumpable */
+ prctl(PR_SET_DUMPABLE,1,0,0,0);
+#endif /* __linux__ */
#endif
Manual of prctl
PR_SET_DUMPABLE
(Since Linux 2.4) Set the state of the flag determining whether core dumps are produced for this process upon delivery of a
signal whose default behaviour is to produce a core dump. (Normally this flag is set for a process by default, but it is
cleared when a set-user-ID or set-group-ID program is executed and also by various system calls that manipulate process UIDs
and GIDs). In kernels up to and including 2.6.12, arg2 must be either 0 (process is not dumpable) or 1 (process is dumpable).
Since kernel 2.6.13, the value 2 is also permitted; this causes any binary which normally would not be dumped to be dumped
readable by root only. (See also the description of /proc/sys/fs/suid_dumpable in proc(5).)
(Since Linux 2.4) Set the state of the flag determining whether core dumps are produced for this process upon delivery of a
signal whose default behaviour is to produce a core dump. (Normally this flag is set for a process by default, but it is
cleared when a set-user-ID or set-group-ID program is executed and also by various system calls that manipulate process UIDs
and GIDs). In kernels up to and including 2.6.12, arg2 must be either 0 (process is not dumpable) or 1 (process is dumpable).
Since kernel 2.6.13, the value 2 is also permitted; this causes any binary which normally would not be dumped to be dumped
readable by root only. (See also the description of /proc/sys/fs/suid_dumpable in proc(5).)
Ref: http://bugs.mysql.com/bug.php?id=21723
Some files about linux core dump:
/proc/sys/fs/suid_dumpable
/etc/profile
/etc/security/limits.conf
/proc/sys/kernel/core_pattern
/etc/profile
/etc/security/limits.conf
/proc/sys/kernel/core_pattern
]]>
Download src code
bzr branch lp:sysbench
make后就可以執(zhí)行了
Percona對這個版本的sysbench的參數(shù)有個不錯的wiki page:
http://www.percona.com/docs/wiki/benchmark:sysbench:olpt.lua
下面這個文章對0.5的sysbench有個比較全面的介紹:
./sysbench --mysql-host=$host1 --mysql-port=3306 --mysql-user=*** --mysql-password=*** --test=/path/to/sysbench/tests/db/oltp.lua --oltp-tables-count=$oltp_table_num --num-threads=$num_thread --max-requests=0 --max-time=$max_time prepare
./sysbench --mysql-host=$host1 --mysql-port=3306 --mysql-user=*** --mysql-password=*** --test=/path/to/sysbench/tests/db/oltp.lua --oltp-tables-count=$oltp_table_num --num-threads=$num_thread --max-requests=0 --max-time=$max_time run
./sysbench --mysql-host=$host1 --mysql-port=3306 --mysql-user=*** --mysql-password=*** --test=/path/to/sysbench/tests/db/oltp.lua --oltp-tables-count=$oltp_table_num --num-threads=$num_thread --max-requests=0 --max-time=$max_time run
補充下，如果要使用 --max-time這個參數(shù)， 需要配合--max-requests=0。
--max-requests=N limit for total number of requests [10000]
如果N=0將取消max-requests的限制]]>
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| test |
+--------------------+
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| test |
+--------------------+
但是用mysqldump去備份這兩個數(shù)據(jù)庫的時候都會報錯
mysqldump: Got error: 1044: Access denied for user 'root'@'localhost' to database 'information_schema' when using LOCK TABLES
mysqldump: Got error: 1142: SELECT,LOCK TABL command denied to user 'root'@'localhost' for table 'cond_instances' when using LOCK TABLES
mysqldump: Got error: 1142: SELECT,LOCK TABL command denied to user 'root'@'localhost' for table 'cond_instances' when using LOCK TABLES
用--all-databases備份時也不會備份這兩個數(shù)據(jù)庫
官方文檔里解釋到：
http://dev.mysql.com/doc/refman/5.5/en/mysqldump.html
總結(jié)一下，如果一定要用mysqldump去備份這兩個數(shù)據(jù)庫不是不可以，但是得disable lock tables。 我用的是：
總結(jié)一下，如果一定要用mysqldump去備份這兩個數(shù)據(jù)庫不是不可以，但是得disable lock tables。 我用的是：
--database information_schema --lock-tables=0
]]>
1. remote file copy
[root@xen74v01 ~]# cat test.pl
#!/usr/bin/perl
print "eth0.74"=~/(\w+)/;
print "\n";
[root@xen74v01 ~]# cat test.pl | ssh 10.1.74.76 'cat - > /tmp/test.pl'
#!/usr/bin/perl
print "eth0.74"=~/(\w+)/;
print "\n";
[root@xen74v01 ~]# cat test.pl | ssh 10.1.74.76 'cat - > /tmp/test.pl'
拷貝文件時，如果文件很大，又不想影響網(wǎng)絡IO可以用pv工具進行流量控制
pv -L10m test.pl | ssh 10.1.74.76 'cat - > /tmp/test.pl'
這里pv的行為跟cat比較類似，但是支持IO流量控制，這里設(shè)置10M/s.2. local script remote execute
[root@xen74v01 ~]# cat test.pl
#!/usr/bin/perl
print "eth0.74"=~/(\w+)/;
print "\n";
[root@xen74v01 ~]# perl test.pl
eth0
[root@xen74v01 ~]# cat test.pl | ssh 10.1.74.76 'perl'
eth0
[root@xen74v01 ~]# ssh 10.1.74.76 'perl' < test.pl
eth0
#!/usr/bin/perl
print "eth0.74"=~/(\w+)/;
print "\n";
[root@xen74v01 ~]# perl test.pl
eth0
[root@xen74v01 ~]# cat test.pl | ssh 10.1.74.76 'perl'
eth0
[root@xen74v01 ~]# ssh 10.1.74.76 'perl' < test.pl
eth0
這樣就不用把腳本拷貝到遠端去執(zhí)行了
參考：
http://linux.icydog.net/ssh/piping.php
http://www.ivarch.com/programs/quickref/pv.shtml
http://www.mysqlperformanceblog.com/2009/05/20/hint-throttling-xtrabackup/
]]>
sub backup {
if (!$option_incremental && !$option_no_lock) {
# make a prep copy before locking tables, if using rsync
backup_files(1);
# flush tables with read lock
mysql_lockall();
}
if ($option_slave_info) {
write_slave_info();
}
}
sub mysql_lockall {
if (compare_versions($mysql_server_version, '4.0.22') == 0
|| compare_versions($mysql_server_version, '4.1.7') == 0) {
# MySQL server version is 4.0.22 or 4.1.7
mysql_send "COMMIT;";
mysql_send "FLUSH TABLES WITH READ LOCK;";
} else {
# MySQL server version is other than 4.0.22 or 4.1.7
mysql_send "FLUSH TABLES WITH READ LOCK;";
mysql_send "COMMIT;";
}
write_binlog_info;
}
if (!$option_incremental && !$option_no_lock) {
# make a prep copy before locking tables, if using rsync
backup_files(1);
# flush tables with read lock
mysql_lockall();
}
if ($option_slave_info) {
write_slave_info();
}
}
sub mysql_lockall {
if (compare_versions($mysql_server_version, '4.0.22') == 0
|| compare_versions($mysql_server_version, '4.1.7') == 0) {
# MySQL server version is 4.0.22 or 4.1.7
mysql_send "COMMIT;";
mysql_send "FLUSH TABLES WITH READ LOCK;";
} else {
# MySQL server version is other than 4.0.22 or 4.1.7
mysql_send "FLUSH TABLES WITH READ LOCK;";
mysql_send "COMMIT;";
}
write_binlog_info;
}
但是如果備份的時候還有很重的workload, "flush tables with read lock" 可能會比較耗時. 這里參考了：
http://www.mysqlperformanceblog.com/2010/04/24/how-fast-is-flush-tables-with-read-lock/
看了下--no-lock的選項說明：
--no-lock
Use this option to disable table lock with "FLUSH TABLES WITH READ
LOCK". Use it only if ALL your tables are InnoDB and you DO NOT CARE
about the binary log position of the backup.
Use this option to disable table lock with "FLUSH TABLES WITH READ
LOCK". Use it only if ALL your tables are InnoDB and you DO NOT CARE
about the binary log position of the backup.
如果我們能保證workload僅僅是innodb相關(guān)的，我們可以使用這個選項。
記得在1.5版本的時候，使用--no-lock選項會導致xtrabackup_slave_info沒有保存?zhèn)浞輹r的logfile & pos. 這個問題在1.6.5被解決了
if ($option_slave_info) {
write_slave_info();
}
write_slave_info();
}
xtrabackup_slave_info & xtrabackup_binlog_info文件在1.5版本是在mysql_lockall函數(shù)里更新的。但是新版本已經(jīng)把write_slave_info提到mysql_lockall外面了。
]]>
IMPORTANT: Please check that the copy-back run completes successfully.
At the end of a successful copy-back run innobackupex-1.6.4
prints "completed OK!".
Original data directory is not empty! at innobackupex-1.6.4 line 544.
At the end of a successful copy-back run innobackupex-1.6.4
prints "completed OK!".
Original data directory is not empty! at innobackupex-1.6.4 line 544.
when read those lines we found that:
# check that original data directories exist and they are empty
if_directory_exists_and_empty($orig_datadir, "Original data");
if_directory_exists_and_empty($orig_ibdata_dir, "Original InnoDB data");
if_directory_exists_and_empty($orig_iblog_dir, "Original InnoDB log");
if_directory_exists_and_empty($orig_datadir, "Original data");
if_directory_exists_and_empty($orig_ibdata_dir, "Original InnoDB data");
if_directory_exists_and_empty($orig_iblog_dir, "Original InnoDB log");
Google for reason for this check and find it mentioned in:
http://www.mysqlperformanceblog.com/2011/12/19/percona-xtrabackup-1-6-4/
innobackupex did not check that MySQL datadir was empty before –copy-back was run. With this bug fix,
innobackupex will now error out of the –copy-back operation if the destination is not empty, avoiding
potential data loss or a strang combination of a restored backup and previous data. Bug Fixed: #737569 (Valentine Gostev)
innobackupex will now error out of the –copy-back operation if the destination is not empty, avoiding
potential data loss or a strang combination of a restored backup and previous data. Bug Fixed: #737569 (Valentine Gostev)
]]>
2. download mysql 5.1 code from trunk
3. autoreconf --force --install
4. ./configure --with-debug --without-libedit --with-plugins=innobase
5. make & sudo make install
6. setup eclipse cdt env
a. startup eclipse by sudo cmd or root user
b. build project
c. set debug diag, ref http://forge.mysql.com/wiki/Eclipse/CDT_on_Linux_and_Mac_OS_X, here is my "program parameters" when startup mysqld instance:
--datadir=/var/lib/mysql --user=mysql --pid-file=/var/run/mysqld/mysqld.pid --port=3306 --socket=/tmp/mysql.sock --default-storage-engine=innodb
]]>
createDB="drop database if exists $database; create database if not exists $database;"
mysql -h $vip --port=$port -uadmin -padmin -e "$createDB"
# prepare data
prepare="$sysbench --test=oltp --mysql-table-engine=innodb --oltp-table-size=$row"
prepare="$prepare --mysql-port=$port --mysql-host=$vip --mysql-db=$database"
prepare="$prepare --mysql-password=admin --mysql-user=admin prepare"
$prepare
# run sysbench
# http://sysbench.sourceforge.net/docs/#database_mode see this link for more options
run="$sysbench --test=oltp --mysql-table-engine=innodb --init-rng --oltp-table-size=$row"
run="$run --max-requests=0 --max-time=900 --num-threads=128 --oltp-test-mode=complex"
run="$run --oltp-point-selects=2 --oltp-simple-ranges=1 --oltp-sum-ranges=2"
run="$run --oltp-index-updates=10 --oltp-non-index-updates=5 --mysql-port=$port"
run="$run --mysql-db=$database --mysql-host=$vip --mysql-password=admin --mysql-user=admin"
# support oltp-user-delay-min to add delay for each sysbench request
if [[ "$lag" != "nolag" ]]
then
run="$run --oltp-user-delay-min=$lag"
fi
run="$run run"
]]>
這個參數(shù)的配置涉及trax提交寫trax log文件的行為
innodb_flush_log_at_trx_commit = 0
# 每秒寫一次trax log,并執(zhí)行fsync
innodb_flush_log_at_trx_commit = 1
# 每次trax 提交的時候?qū)懸淮蝨rax log, 并執(zhí)行fsync
innodb_flush_log_at_trx_commit = 2
# 每次trax 提交的時候?qū)懸淮蝨rax log, 不會執(zhí)行fsync
# 每秒寫一次trax log,并執(zhí)行fsync
innodb_flush_log_at_trx_commit = 1
# 每次trax 提交的時候?qū)懸淮蝨rax log, 并執(zhí)行fsync
innodb_flush_log_at_trx_commit = 2
# 每次trax 提交的時候?qū)懸淮蝨rax log, 不會執(zhí)行fsync
]]>
- ./configure ... '--with-charset=utf8' '--with-collation=utf8_general_ci' ...
- make & make install
- start mysql instance
驗證：
也可以在my.cnf里面修改默認字符集：
default-character-set=latin1
]]>