innodb插件方式安装myql 5.1

yum install gcc gcc-c++

groupadd mysql
useradd –shell /sbin/nologin -g mysql mysql
tar zxvf mysql-5.1.58.tar.gz
cd mysql-5.1.58

 

#设置一下 CFLAGS 和 CXXFLAGS,尤其要注意打开 HAVE_DLOPEN 选项
CFLAGS=’-O2 -DHAVE_DLOPEN -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector –param=ssp-buffer-size=4 -m64 -mtune=generic’

CXXFLAGS=’-O2 -DHAVE_DLOPEN -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector –param=ssp-buffer-size=4 -m64 -mtune=generic’

./configure –prefix=/data1/app/services/mysql
–with-charset=utf8
–with-collation=utf8_general_ci
–with-extra-charsets=complex
–enable-thread-safe-client
–enable-local-infile
–enable-assembler
–with-big-tables
–localstatedir=/data1/app/services/mysql/data
–with-unix-socket-path=/data1/app/tmp/mysql.sock
–with-mysqld-user=mysql
–with-plugins=max-no-ndb

make
make install

cp support-files/my-medium.cnf /etc/my.cnf
cp support-files/mysql.server /etc/init.d/mysql
chmod u+x /etc/init.d/mysql

cd /data1/app/services/mysql
bin/mysql_install_db –user=mysql –force –datadir=data
chown -R root  .
chown -R mysql data
chgrp -R mysql .

chkconfig –add mysql
chkconfig –level 345 mysql on
bin/mysqld_safe –user=mysql &
service mysql restart

 

ln -s /data1/app/mysql52/bin/mysql /sbin/mysql
ln -s /data1/app/mysql52/mysqladmin /sbin/mysqladmin

 

my.cnf文件参考(注意红色部分):

[mysqld]
datadir=/data1/app/services/mysql/data
socket=/data1/app/tmp/mysql.sock
pid-file=/data1/app/tmp/mysql.pid
user=mysql
port=3308

ignore-builtin-innodb
plugin-load=innodb=ha_innodb_plugin.so

# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).

old_passwords=1

character-set-server = utf8
collation-server = utf8_general_ci
default-storage-engine=INNODB

skip-name-resolve
skip-external-locking
key_buffer = 16M
max_allowed_packet = 1M
table_cache = 32512
sort_buffer_size = 2M
read_buffer_size = 2M
read_rnd_buffer_size = 2M
myisam_sort_buffer_size = 8M
thread_cache_size = 32
query_cache_size = 8M
tmp_table_size = 64M

# Try number of CPU’s*2 for thread_concurrency
thread_concurrency = 16
lower_case_table_names = 1
max_connections = 100

slow_query_log_file = /data1/app/log/mysql-slow.log
slow_query_log = 1
log-queries-not-using-indexes
long_query_time = 1
wait_timeout = 86400

log-bin = mysql-bin
server-id = 1
expire-logs-days = 7

innodb_buffer_pool_size = 256M
innodb_additional_mem_pool_size = 16M
innodb_file_per_table
innodb_open_files = 65535
innodb_lock_wait_timeout = 50
innodb_log_file_size = 512M
innodb_log_buffer_size = 16M
innodb_flush_method = O_DIRECT
innodb_flush_log_at_trx_commit = 2

binlog_format = mixed
transaction-isolation = READ-UNCOMMITTED

[mysqld_safe]
log-error=/data1/app/log/mysql.log

 

启动数据库进去看下:

[root@fbtw-topcity log]# mysql -h 127.0.0.1 -P 3308
Welcome to the MySQL monitor.  Commands end with ; or g.
Your MySQL connection id is 2
Server version: 5.1.58-log Source distribution

Type ‘help;’ or ‘h’ for help. Type ‘c’ to clear the buffer.

mysql> show plugin;         
+————+———-+—————-+———————+———+
| Name       | Status   | Type           | Library             | License |
+————+———-+—————-+———————+———+
| binlog     | ACTIVE   | STORAGE ENGINE | NULL                | GPL     |
| partition  | ACTIVE   | STORAGE ENGINE | NULL                | GPL     |
| ARCHIVE    | ACTIVE   | STORAGE ENGINE | NULL                | GPL     |
| BLACKHOLE  | ACTIVE   | STORAGE ENGINE | NULL                | GPL     |
| CSV        | ACTIVE   | STORAGE ENGINE | NULL                | GPL     |
| FEDERATED  | DISABLED | STORAGE ENGINE | NULL                | GPL     |
| MEMORY     | ACTIVE   | STORAGE ENGINE | NULL                | GPL     |
| MyISAM     | ACTIVE   | STORAGE ENGINE | NULL                | GPL     |
| MRG_MYISAM | ACTIVE   | STORAGE ENGINE | NULL                | GPL     |
| InnoDB     | ACTIVE   | STORAGE ENGINE | ha_innodb_plugin.so | GPL     |
+————+———-+—————-+———————+———+
10 rows in set, 1 warning (0.00 sec)

mysql> show variables like ‘innodb_%’;
+———————————+————————+
| Variable_name                   | Value                  |
+———————————+————————+
| innodb_adaptive_flushing        | ON                     |
| innodb_adaptive_hash_index      | ON                     |
| innodb_additional_mem_pool_size | 16777216               |
| innodb_autoextend_increment     | 8                      |
| innodb_autoinc_lock_mode        | 1                      |
| innodb_buffer_pool_size         | 268435456              |
| innodb_change_buffering         | inserts                |
| innodb_checksums                | ON                     |
| innodb_commit_concurrency       | 0                      |
| innodb_concurrency_tickets      | 500                    |
| innodb_data_file_path           | ibdata1:10M:autoextend |
| innodb_data_home_dir            |                        |
| innodb_doublewrite              | ON                     |
| innodb_fast_shutdown            | 1                      |
| innodb_file_format              | Antelope               |
| innodb_file_format_check        | Antelope               |
| innodb_file_per_table           | ON                     |
| innodb_flush_log_at_trx_commit  | 2                      |
| innodb_flush_method             | O_DIRECT               |
| innodb_force_recovery           | 0                      |
| innodb_io_capacity              | 200                    |
| innodb_lock_wait_timeout        | 50                     |
| innodb_locks_unsafe_for_binlog  | OFF                    |
| innodb_log_buffer_size          | 16777216               |
| innodb_log_file_size            | 536870912              |
| innodb_log_files_in_group       | 2                      |
| innodb_log_group_home_dir       | ./                     |
| innodb_max_dirty_pages_pct      | 75                     |
| innodb_max_purge_lag            | 0                      |
| innodb_mirrored_log_groups      | 1                      |
| innodb_old_blocks_pct           | 37                     |
| innodb_old_blocks_time          | 0                      |
| innodb_open_files               | 65535                  |
| innodb_read_ahead_threshold     | 56                     |
| innodb_read_io_threads          | 4                      |
| innodb_replication_delay        | 0                      |
| innodb_rollback_on_timeout      | OFF                    |
| innodb_spin_wait_delay          | 6                      |
| innodb_stats_method             | nulls_equal            |
| innodb_stats_on_metadata        | ON                     |
| innodb_stats_sample_pages       | 8                      |
| innodb_strict_mode              | OFF                    |
| innodb_support_xa               | ON                     |
| innodb_sync_spin_loops          | 30                     |
| innodb_table_locks              | ON                     |
| innodb_thread_concurrency       | 0                      |
| innodb_thread_sleep_delay       | 10000                  |
| innodb_use_sys_malloc           | ON                     |
| innodb_version                  | 1.0.17                 |
| innodb_write_io_threads         | 4                      |
+———————————+————————+
50 rows in set (0.02 sec)

mysql>

innodb_log_file_size设多大是合适的?

INNODB_LOG_FILE 过于小,会直接触发CHECKPOINT,导致频繁IO请求; 多大是合适的?

    ========================================
    : (none) 16:13:13> pager grep sequence               
    PAGER set to ‘grep sequence’
    : (none) 16:13:14>
    : (none) 16:13:15>  SHOW engine innodb STATUSG SELECT sleep(60); SHOW engine innodb STATUSG               
    Log sequence number 1450 485101299
    1 row in set (0.09 sec)
   
   
    1 row in set (1 min 0.01 sec)
   
    Log sequence number 1450 505024667
    1 row in set (0.00 sec)
   
    : (none) 16:14:37> nopager
    PAGER set to stdout
    : (none) 16:14:43> select (505024667-485101299)/1024/1024;
    +———————————+
    | (505024667-485101299)/1024/1024 |
    +———————————+
    |                     19.00040436 |
    +———————————+
    1 row in set (0.00 sec)
    ========================================
    Notice the log sequence number. That’s the total number of bytes written to the transaction log.
    我们在高峰期间采样可以得到,1分钟产生19M的日志; 我觉得这个INNODB LOG大小设成 19M*60=1140M 已经足够了;
    60分钟是一个经验值, 你也可以适当调大,比如 500M,3个文件 ;这相对来说是安全的;
    当然你也可以用以下命令来查看日志产生的大小:
    show status like ‘Innodb_os_log_written’; select sleep(60); show status like ‘Innodb_os_log_written’;

详解show innodb status(转)

(翻译了mysqlperformance blog的文章,网址为http://www.mysqlperformanceblog.com/2006/07/17/show-innodb-status-walk-through/,英文不好,大家见笑)

在show innodb status中,现实的值是每秒中的。确保数据是20-30秒之间的一个抽样,若
将计算时间运行为0或1秒左右的数据抽样,所得的信息是没有意义的。

1、开始信息为数据抽样的时间间隔
CODE:
1.=====================================
2.060717  3:07:56 INNODB MONITOR OUTPUT
3.=====================================
4.Per second averages calculated from the last 44 seconds

2、下面是信号量的信息

CODE:
1.———-
2.SEMAPHORES
3.———-
4.OS WAIT ARRAY INFO: reservation count 13569, signal count 11421
5.–Thread 1152170336 has waited at ./../include/buf0buf.ic line 630 for 0.00 seconds the semaphore:
6.Mutex at 0×2a957858b8 created file buf0buf.c line 517, lock var 0
7.waiters flag 0
8.wait is ending
9.–Thread 1147709792 has waited at ./../include/buf0buf.ic line 630 for 0.00 seconds the semaphore:
10.Mutex at 0×2a957858b8 created file buf0buf.c line 517, lock var 0
11.waiters flag 0
12.wait is ending
13.Mutex spin waits 5672442, rounds 3899888, OS waits 4719
14.RW-shared spins 5920, OS waits 2918; RW-excl spins 3463, OS waits 3163

在这一块,有两部分内容。一部分是列出当前的等待。它只有在高度并发的环境下,导致innodb不得不频繁进入
os的等待时才会显示。如果通过旋转锁的方式解决这个问题,这一部分将不会出现。
通过此块信息,可以得知当前访问的热点。(但需要对mysql源码有一定了解)
“lock var”的当前值代表的互斥体的状态(locked=1/free=0)
“waiters flag”是当前等待的数量。另外”wait is ending”在此处表示互斥对象已经释放,但os还没有分配线程,
所以继续执行
第二部分的信息是对事件的计数,”reservation count”和”signal count”显示了当前的innodb使用了多少同步数组,
slot被分配给innodb、线程被信号通知使用同步数组的频度。这些计数可以被用于显示innodb需要进入os等待的频度
,通过os waits获得又读写锁、互斥体引起的系统等待。
spin waits和spin rounds是另一个重要的信息。比起os wait,旋转锁的等待开销相对小。但它占用cpu
可也通过调节innodb_sync_spin_loops来适当改变。

下面的信息是关于死锁的
CODE:
1.————————
2.LATEST DETECTED DEADLOCK
3.————————
4.060717  4:16:48
5.*** (1) TRANSACTION:
6.TRANSACTION 0 42313619, ACTIVE 49 sec, process no 10099, OS thread id 3771312 starting index read
7.mysql tables in use 1, locked 1
8.LOCK WAIT 3 lock struct(s), heap size 320
9.MySQL thread id 30898, query id 100626 localhost root Updating
10.update iz set pad=’a’ where i=2
11.*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
12.RECORD LOCKS space id 0 page no 16403 n bits 72 index `PRIMARY` of table `test/iz` trx id 0 42313619 lock_mode X locks rec but not gap waiting
13.Record lock, heap no 5 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
14. 0: len 4; hex 80000002; asc     ;; 1: len 6; hex 00000285a78f; asc       ;; 2: len 7; hex 00000040150110; asc    @   ;; 3: len 10; hex 61202020202020202020; asc a         ;;
15.
16.*** (2) TRANSACTION:
17.TRANSACTION 0 42313620, ACTIVE 24 sec, process no 10099, OS thread id 4078512 starting index read, thread declared inside InnoDB 500
18.mysql tables in use 1, locked 1
19.3 lock struct(s), heap size 320
20.MySQL thread id 30899, query id 100627 localhost root Updating
21.update iz set pad=’a’ where i=1
22.*** (2) HOLDS THE LOCK(S):
23.RECORD LOCKS space id 0 page no 16403 n bits 72 index `PRIMARY` of table `test/iz` trx id 0 42313620 lock_mode X locks rec but not gap
24.Record lock, heap no 5 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
25. 0: len 4; hex 80000002; asc     ;; 1: len 6; hex 00000285a78f; asc       ;; 2: len 7; hex 00000040150110; asc    @   ;; 3: len 10; hex 61202020202020202020; asc a         ;;
26.
27.*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
28.RECORD LOCKS space id 0 page no 16403 n bits 72 index `PRIMARY` of table `test/iz` trx id 0 42313620 lock_mode X locks rec but not gap waiting
29.Record lock, heap no 4 PHYSICAL RECORD: n_fields 4; compact format; info bits 0
30. 0: len 4; hex 80000001; asc     ;; 1: len 6; hex 00000285a78e; asc       ;; 2: len 7; hex 000000003411d9; asc     4  ;; 3: len 10; hex 61202020202020202020; asc a         ;;
31.
32.*** WE ROLL BACK TRANSACTION (2)

对于上次死锁,显示了什么造成了死锁,在死锁时的状态,它们持有了哪些锁,在等待那些innodb决定将哪个事务回滚。它只是简单的描述,要了解细节,会需要查看binlog

同死锁类似,我们可以获得最近一次外键限制失败的简单信息

CODE:
1.————————
2.LATEST FOREIGN KEY ERROR
3.————————
4.060717  4:29:00 Transaction:
5.TRANSACTION 0 336342767, ACTIVE 0 sec, process no 3946, OS thread id 1151088992 inserting, thread declared inside InnoDB 500
6.mysql tables in use 1, locked 1
7.3 lock struct(s), heap size 368, undo log entries 1
8.MySQL thread id 9697561, query id 188161264 localhost root update
9.insert into child values(2,2)
10.Foreign key constraint fails for table `test/child`:
11.,
12.  CONSTRAINT `child_ibfk_1` FOREIGN KEY (`parent_id`) REFERENCES `parent` (`id`) ON DELETE CASCADE
13.Trying to add in child table, in index `par_ind` tuple:
14.DATA TUPLE: 2 fields;
15. 0: len 4; hex 80000002; asc     ;; 1: len 6; hex 000000000401; asc       ;;
16.
17.But in parent table `test/parent`, in index `PRIMARY`,
18.the closest match we can find is record:
19.PHYSICAL RECORD: n_fields 3; 1-byte offs TRUE; info bits 0
20. 0: len 4; hex 80000001; asc     ;; 1: len 6; hex 0000140c2d8f; asc     – ;; 2: len 7; hex 80009c40050084; asc    @   ;;

innodb将打印引起错误的语句、相应的外键定义以及在父表中最近的记录。

下面是关于当前活动的事务的状态
CODE:
1.————
2.TRANSACTIONS
3.————
4.Trx id counter 0 80157601
5.Purge done for trx’s n:o <0 80154573 undo n:o <0 0
6.History list length 6
7.Total number of lock structs in row lock hash table 0
8.LIST OF TRANSACTIONS FOR EACH SESSION:
9.—TRANSACTION 0 0, not started, process no 3396, OS thread id 1152440672
10.MySQL thread id 8080, query id 728900 localhost root
11.show innodb status
12.—TRANSACTION 0 80157600, ACTIVE 4 sec, process no 3396, OS thread id 1148250464, thread declared inside InnoDB 442
13.mysql tables in use 1, locked 0
14.MySQL thread id 8079, query id 728899 localhost root Sending data
15.select sql_calc_found_rows  * from b limit 5
16.Trx read view will not see trx with id>= 0 80157601, sees <0 80157597
17.—TRANSACTION 0 80157599, ACTIVE 5 sec, process no 3396, OS thread id 1150142816 fetching rows, thread declared inside InnoDB 166
18.mysql tables in use 1, locked 0
19.MySQL thread id 8078, query id 728898 localhost root Sending data
20.select sql_calc_found_rows  * from b limit 5
21.Trx read view will not see trx with id>= 0 80157600, sees <0 80157596
22.—TRANSACTION 0 80157598, ACTIVE 7 sec, process no 3396, OS thread id 1147980128 fetching rows, thread declared inside InnoDB 114
23.mysql tables in use 1, locked 0
24.MySQL thread id 8077, query id 728897 localhost root Sending data
25.select sql_calc_found_rows  * from b limit 5
26.Trx read view will not see trx with id>= 0 80157599, sees <0 80157595
27.—TRANSACTION 0 80157597, ACTIVE 7 sec, process no 3396, OS thread id 1152305504 fetching rows, thread declared inside InnoDB 400
28.mysql tables in use 1, locked 0
29.MySQL thread id 8076, query id 728896 localhost root Sending data
30.select sql_calc_found_rows  * from b limit 5
31.Trx read view will not see trx with id>= 0 80157598, sees <0 80157594

如果只有少量的连接,将会列出所有的事务列表,Purge done for trx’s n:o表示已经清除的事务号,innodb只能清除潜在不使用的事务号,
旧的未提交的事务将会阻塞清除进程,占用资源。通过当前的事务号和清理的事务号的差可以获得相应当前的事务数。
histor list length 6 是在未做空间中未清理的事务。它随着更新和提交事务的增多而增多,随着清理工作而减少。
Total number of lock structs in row lock hash table 是所有事务锁结构分配的数量。注意这不是被锁的行的数量,每个锁会锁住多行。
如果一个连接中,没有运行的事务则显示not started,否则显示active。注:如果是多语句事务,即使处在sleep阶段,也可以是active。
innodb还会显示os的线程id和进程id,这对于使用gdb调试程序时很有用。同时还显示了事务的状态,如fetching或updating。
“Thread declared inside InnoDB 400″表示线程在innodb的内核中运行,还有400个tickets使用。通过使用innodb_thread_concurrency
调节并发在innodb内核中的线程数。如果线程未运行在innodb内核中,其状态显示为waitting in innodb queue或sleeping before joining innodb queue
innodb会让线程在进入等待前先sleep一段时间(当没有足够的slot可用的时候)。这可能使active的线程数小于innodb_thread_concurrency的值。
对此,可以调节innodb_thread_sleep_delay变量来调节sleep的时间长短。它以毫秒计算。
mysql tables in use 1, locked 0显示了该事务使用的表的数量和使用的锁,除非使用alter table或lock table等语句,一般情况innodb不加锁

下面是文件输入输出的信息:
CODE:
1.——–
2.FILE I/O
3.——–
4.I/O thread 0 state: waiting for i/o request (insert buffer thread)
5.I/O thread 1 state: waiting for i/o request (log thread)
6.I/O thread 2 state: waiting for i/o request (read thread)
7.I/O thread 3 state: waiting for i/o request (write thread)
8.Pending normal aio reads: 0, aio writes: 0,
9. ibuf aio reads: 0, log i/o’s: 0, sync i/o’s: 0
10.Pending flushes (fsync) log: 0; buffer pool: 0
11.17909940 OS file reads, 22088963 OS file writes, 1743764 OS fsyncs
12.0.20 reads/s, 16384 avg bytes/read, 5.00 writes/s, 0.80 fsyncs/s

显示了辅助线程insert buffer thread, log thread, read thread和write thread的当前状态。在每个辅助线程上挂起的操作数也显示出来。
同时也显示了挂起的fsync操作。”16384 avg bytes/read”显示了读请求的平均大小。

CODE:
1.————————————-
2.INSERT BUFFER AND ADAPTIVE HASH INDEX
3.————————————-
4.Ibuf for space 0: size 1, free list len 887, seg size 889, is not empty
5.Ibuf for space 0: size 1, free list len 887, seg size 889,
6.2431891 inserts, 2672643 merged recs, 1059730 merges
7.Hash table size 8850487, used cells 2381348, node heap has 4091 buffer(s)
8.2208.17 hash searches/s, 175.05 non-hash searches/s

此处显示了插入缓存和调节hash表的使用状况。number of merges与number of pretty的比率显示了插入缓存的效率
通过non-hash searches比hash searches的值可知hash表的效率。
但无法调节insert buffer 和adjust hash table。

CODE:
1.—
2.LOG
3.—
4.Log sequence number 84 3000620880
5.Log flushed up to   84 3000611265
6.Last checkpoint at  84 2939889199
7.0 pending log writes, 0 pending chkp writes
8.14073669 log i/o’s done, 10.90 log i/o’s/second

log sequence number 显示了innodb向log中写入的bytes。也可得知当前log被flushed到哪一点,通过此可以检验innodb_log_buffer_size的理想状况,
若有30%的数据没有被flush入log中,应该适当增大innodb_log_buffer_size。

 CODE:
1.———————-
2.BUFFER POOL AND MEMORY
3.———————-
4.Total memory allocated 4648979546; in additional pool allocated 16773888
5.Buffer pool size   262144
6.Free buffers       0
7.Database pages     258053
8.Modified db pages  37491
9.Pending reads 0
10.Pending writes: LRU 0, flush list 0, single page 0
11.Pages read 57973114, created 251137, written 10761167
12.9.79 reads/s, 0.31 creates/s, 6.00 writes/s
13.Buffer pool hit rate 999 / 1000

此节信息表明了buffer pool的效率和内存的使用。可获得innodb分配的所有内存,额外的分配的池,buffer pool中的页面数量,free页面的数量,
和脏数据页。由此可以作为依据调节buffer pool的大小,即使free页为0,database pases也将不等于buffer pool的所有大小,因为buffer pool也存入了
锁信息,调节的hash索引,和其他系统结构。
pending reads 和writes 表明了在buffer pool级别悬挂的请求。innodb将多个请求合并到一个文件级别,这里是不同的。此外,还可看到其他的io提交信息,
LRU——用最近最少使用算法换出的脏数据页; flush list:需要通过checkpointing进程刷新的旧页面;single page:独立的页面写操作。
也可看到正在被读写创建的数据页。最后还可看到buffer pool的命中率。

CODE:
1.————–
2.ROW OPERATIONS
3.————–
4.0 queries inside InnoDB, 0 queries in queue
5.1 read views open inside InnoDB
6.Main thread process no. 10099, id 88021936, state: waiting for server activity
7.Number of rows inserted 143, updated 3000041, deleted 0, read 24865563
8.0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s

最后一节信息:以行为基础,显示行操作的数量,及一些系统信息。此处信息相对简单易读,不作介绍。

MySQL5.1复制参数binlog_format (转)

本文转自:http://lincolnhuang.wordpress.com/2011/05/05/mysql5-1%E5%A4%8D%E5%88%B6%E5%8F%82%E6%95%B0binlog_format/ 感谢作者!

一、简介
MySQL 5.1 中,在复制方面的改进就是引进了新的复制技术:基于行的复制。
简言之,这种新技术就是关注表中发生变化的记录,而非以前的照抄 binlog 模式。
从 MySQL 5.1.12 开始,可以用以下三种模式来实现:
基于SQL语句的复制(statement-based replication, SBR)
基于行的复制(row-based replication, RBR)
混合模式复制(mixed-based replication, MBR)。
相应地,binlog的格式也有三种:STATEMENT,ROW,MIXED。
SBR 模式是默认的。

在运行时可以动态低改变binlog的格式,除了以下几种情况:
1. 存储过程或者触发器中间
2. 启用了NDB
3. 当前会话试用 RBR 模式,并且已打开了临时表

如果binlog采用了 MIXED 模式,那么在以下几种情况下会自动将binlog的模式由 SBR 模式改成 RBR 模式。
1. 当DML语句更新一个NDB表时
2. 当函数中包含 UUID() 时
3. 2个及以上包含 AUTO_INCREMENT 字段的表被更新时
4. 行任何 INSERT DELAYED 语句时
5. 用 UDF 时
6. 视图中必须要求使用 RBR 时,例如创建视图是使用了 UUID() 函数

二、设置方法
设定主从复制模式的方法非常简单,只要在以前设定复制配置的基础上,再加一个参数:
binlog_format=”STATEMENT”
binlog_format=”ROW”
binlog_format=”MIXED”

当然了,也可以在运行时动态修改binlog的格式。例如:
mysql> SET SESSION binlog_format = ‘STATEMENT’;
mysql> SET SESSION binlog_format = ‘ROW’;
mysql> SET SESSION binlog_format = ‘MIXED’;

mysql> SET GLOBAL binlog_format = ‘STATEMENT’;
mysql> SET GLOBAL binlog_format = ‘ROW’;
mysql> SET GLOBAL binlog_format = ‘MIXED’;

三、优缺点
现在来比较以下 SBR 和 RBR 两种模式各自的优缺点
SBR 的优点:
1. 历史悠久,技术成熟
2. binlog文件较小
3. binlog中包含了所有数据库更改信息,可以据此来审核数据库的安全等情况
4. binlog可以用于实时的还原,而不仅仅用于复制
5. 主从版本可以不一样,从服务器版本可以比主服务器版本高

SBR 的缺点:
1. 不是所有的UPDATE语句都能被复制,尤其是包含不确定操作的时候。
2. 调用具有不确定因素的 UDF 时复制也可能出问题
3. 使用以下函数的语句也无法被复制:
* LOAD_FILE()
* UUID()
* USER()
* FOUND_ROWS()
* SYSDATE() (除非启动时启用了 –sysdate-is-now 选项)
4. INSERT … SELECT 会产生比 RBR 更多的行级锁
5. 复制需要进行全表扫描(WHERE 语句中没有使用到索引)的 UPDATE 时,需要比 RBR 请求更多的行级锁
6. 对于有 AUTO_INCREMENT 字段的 InnoDB表而言,INSERT 语句会阻塞其他 INSERT 语句
7. 对于一些复杂的语句,在从服务器上的耗资源情况会更严重,而 RBR 模式下,只会对那个发生变化的记录产生影响
8. 存储函数(不是存储过程)在被调用的同时也会执行一次 NOW() 函数,这个可以说是坏事也可能是好事
9. 确定了的 UDF 也需要在从服务器上执行
10. 数据表必须几乎和主服务器保持一致才行,否则可能会导致复制出错
11. 执行复杂语句如果出错的话,会消耗更多资源

RBR 的优点:
1. 任何情况都可以被复制,这对复制来说是最安全可靠的
2. 和其他大多数数据库系统的复制技术一样
3. 多数情况下,从服务器上的表如果有主键的话,复制就会快了很多
4. 复制以下几种语句时的行锁更少:
* INSERT … SELECT
* 包含 AUTO_INCREMENT 字段的 INSERT
* 没有附带条件或者并没有修改很多记录的 UPDATE 或 DELETE 语句
5. 执行 INSERT,UPDATE,DELETE 语句时锁更少
6. 从服务器上采用多线程来执行复制成为可能

RBR 的缺点:
1. binlog 大了很多
2. 复杂的回滚时 binlog 中会包含大量的数据
3. 主服务器上执行 UPDATE 语句时,所有发生变化的记录都会写到 binlog 中,而 SBR 只会写一次,这会导致频繁发生binlog 的并发写问题
4. UDF 产生的大 BLOB 值会导致复制变慢
5. 无法从 binlog 中看到都复制了写什么语句
6. 当在非事务表上执行一段堆积的SQL语句时,最好采用 SBR 模式,否则很容易导致主从服务器的数据不一致情况发生

另外,针对系统库 mysql 里面的表发生变化时的处理规则如下:
1. 如果是采用 INSERT,UPDATE,DELETE 直接操作表的情况,则日志格式根据 binlog_format 的设定而记录
2. 如果是采用 GRANT,REVOKE,SET PASSWORD 等管理语句来做的话,那么无论如何都采用 SBR 模式记录
注:采用 RBR 模式后,能解决很多原先出现的主键重复问题

innodb_log_file_size参数调整要慎之又慎!!!

如果innodb_log_file_size以前是256M,现在要调整到512M,那么更改配置后,你将无法启动mysql,这个参数调整特别是有数据时需要慎之又慎!!!发这篇个文章主要是为了提醒我自己,以前吃过这方面的亏,还好当时是测试服务器。

 

那万一碰到后怎么办呢?

先改回去试试,能成功启动的话再导出数据做备份。再:

要STOP服务先,然后再删除原来的文件………
打开/var/lib/mysql
删除ib_logfile0, ib_logfile1……..ib_logfilen
再开启选项,成功启动。

mysql 5.1.57主备配置文件备忘

mysql 5.1跟mysql 5.0有很多配置参数已经更改了,甚至最新的mysql 5.1.57和早一些的mysql 5.1,比如mysql 5.1.1x之类的,都有不少配置参数的更改,真是搞不懂为什么?其实实现的功能基本是一致的。

贴上最近做的一个Mysql 5.1.57主备的安装和配置在这里,备忘:

我这两台机器的内存都很大,每台48G。不过目前的数据量还很小。

安装:

# yum install gcc gcc-c++
# groupadd mysql
# useradd –shell /sbin/nologin -g mysql mysql
# tar zxvf mysql-5.1.57.tar.gz
# cd mysql-5.1.57

# ./configure –prefix=/data1/app/services/mysql51
            –localstatedir=/data1/app/services/mysql51/data
            –with-charset=utf8
            –with-collation=utf8_general_ci
            –with-extra-charsets=gb2312,gbk,utf8
            –with-plugins=max-no-ndb
            –with-unix-socket-path=/data1/app/tmp/mysql.sock
            –with-mysqld-user=mysql
            –enable-local-infile
            –enable-assembler
            –with-client-ldflags=-all-static
            –with-mysqld-ldflags=-all-static
            –enable-thread-safe-client

# make

# make install

 

配置文件:

主:

[mysqld]
datadir=/data1/app/services/mysql51/data
socket=/data1/app/tmp/mysql.sock
pid-file=/data1/app/tmp/mysqld.pid
user=mysql

# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).

old_passwords=1

character-set-server = utf8
collation-server = utf8_general_ci
default-storage-engine=INNODB

skip-name-resolve
skip-external-locking
key_buffer = 1024M
max_allowed_packet = 1M
table_cache = 32512
sort_buffer_size = 2M
read_buffer_size = 2M
read_rnd_buffer_size = 2M
myisam_sort_buffer_size = 32M
thread_cache_size = 32
query_cache_size = 32M
tmp_table_size = 1G

# Try number of CPU’s*2 for thread_concurrency
thread_concurrency = 16
lower_case_table_names = 1
max_connections = 1200

slow_query_log_file = /data1/app/log/mysqld-slow.log
slow_query_log = 1
log-queries-not-using-indexes
long_query_time = 1
wait_timeout = 86400

log-bin = mysql-bin
server-id = 1
expire-logs-days = 7
#binlog-do-db = db1

#binlog-do-db = db2

innodb_buffer_pool_size = 8G
innodb_additional_mem_pool_size = 256M
innodb_file_per_table
innodb_open_files = 65535
innodb_lock_wait_timeout = 50
innodb_log_file_size = 1G
innodb_log_buffer_size = 128M
innodb_flush_method = O_DIRECT
innodb_flush_log_at_trx_commit = 2

binlog_format = mixed
transaction-isolation = READ-UNCOMMITTED

[mysqld_safe]
log-error=/data1/app/log/mysqld.log

 

备:

[mysqld]
datadir=/data1/app/services/mysql51/data
socket=/data1/app/tmp/mysql.sock
pid-file=/data1/app/tmp/mysqld.pid
user=mysql
# Default to using old password format for compatibility with mysql 3.x
# clients (those using the mysqlclient10 compatibility package).
old_passwords=1

character-set-server = utf8
collation-server = utf8_general_ci
default-storage-engine=INNODB

skip-name-resolve
skip-external-locking
key_buffer = 256M
max_allowed_packet = 1M
table_cache = 32512
sort_buffer_size = 4M
read_buffer_size = 4M
read_rnd_buffer_size = 4M
myisam_sort_buffer_size = 16M
thread_cache_size = 32
query_cache_size = 16M
tmp_table_size = 1G
# Try number of CPU’s*2 for thread_concurrency
thread_concurrency = 16
lower_case_table_names = 1
max_connections = 1200

slow_query_log_file = /data1/app/log/mysqld-slow.log
slow_query_log = 1
log-queries-not-using-indexes
long_query_time = 1
wait_timeout = 86400

log-bin = mysql-bin
relay-log = mysql-relay-log
relay-log-index = mysql-relay-index
log_slave_updates = 1

server-id = 2
#master-host = 10.0.0.32
#master-user = repl
#master-password = password
#master-port = 3306
#master-connect-retry = 10
expire-logs-days = 7
replicate-do-db = db1
replicate-do-db = db2
#replicate-ignore-db=test
report-host = 10.0.0.33

innodb_buffer_pool_size = 8G
innodb_additional_mem_pool_size = 256M
innodb_file_per_table
innodb_open_files = 65535
innodb_lock_wait_timeout = 50
innodb_log_file_size = 1G
innodb_log_buffer_size = 128M
innodb_flush_method = O_DIRECT
innodb_flush_log_at_trx_commit = 2

binlog_format = mixed
transaction-isolation = READ-UNCOMMITTED

[mysqld_safe]
log-error=/data1/app/log/mysqld.log

 

备机的主服务器配置信息不再配置在my.cnf内了,启动后执行以下SQL配置:

 CHANGE MASTER TO MASTER_HOST=’10.0.0.32′,
MASTER_USER=’repl’,
MASTER_PASSWORD=’password’,
MASTER_PORT=3306,
MASTER_CONNECT_RETRY=10;

 

 

另外关于innodb_buffer_pool_size参数,今天看了一下这篇文章:

http://www.mysqlperformanceblog.com/2007/11/03/choosing-innodb_buffer_pool_size/

主要讲的是关于innodb_buffer_pool_size参数的配置的,大致就是两个方向:

1. 如果mysql innodb的数据量小于物理内存,那么innodb_buffer_pool_size配置为数据量大小+10%,然后再考虑下数据增长,适当调整。

2. 如果mysql innodb的数据量小于物理内存,那么innodb_buffer_pool_size配置应该尽量大,这样可以最大限度的增加缓冲,减少IO。

但是配置时需要注意用物理内存减去其它方面的内存开销,这些开销有:

1) 操作系统的内存开销,这个包括一些系统进程,页表,socket连接的缓冲等一般留个1G左右就够了。

2) innodb正常情况下还有大约8%的开销,主要用在每个缓存页帧的描述、adaptive hash等数据结构,如果不是安全关闭,启动时还要恢复的话,还要另开大约12%的内存用于恢复,两者相加就有差不多21%的开销。

3)数据库连接方面的内存开销,下面有计算公式。

4) query cache, key_buffer, mysql threads, temporary tables, per thread sort buffer等的开销。

5)其它应用程序的内存开销,如果有的话。

在这种情况下,用物理内存减去上面几个方面的内存开销。同时参考用Mysql 5.1手册上的计算公式来确定这个值:

innodb_buffer_pool_size

+ key_buffer_size

+ max_connections*(sort_buffer_size+read_buffer_size+binlog_cache_size)

+ max_connections*2MB

每个线程使用一个堆栈(通常是2MB,但在MySQL AB二进制分发版里只有256KB)并且在最坏的情况下也使用sort_buffer_size + read_buffer_size附加内存。

另个还有两个注意的地方:

1)避免双重缓冲,innodb用了innodb_buffer_pool,操作系统层面还有一个缓冲。这样就双重缓冲了,没有必要,反而加大了系统的负载,速度也慢了。可以配置innodb_flush_method = O_DIRECT跳过操作系统的缓冲,直接写入磁盘。

2)避免操作系统对mysql进程做页面交换。如果物理内存不够的时候,操作系统会把当前进程使用的内存先存到磁盘的虚拟内存,然后把空出来的内存给新的需要的进程使用。这方面需要保持有足够的内存,在linux上不想用虚拟内存,可以配置内核参数:

# vim /etc/sysctl.conf

vm.swappiness = 5

# sysctl -p

默认是60,这个数字越高,使用虚拟内存的机率也越高,我设置5,意思意思就行了。需要注意的是,就算设成0也不表示不使用虚拟内存了,物理内存不够时,依然会用到的。

 

MySQL 主从同步错误(error)解决(转)

1出现错误(error)提示

 

Slave I/O: error connecting to master ‘backup@192.168.1.x:3306’ – retry-time: 60  retries: 86400, Error_code: 1045

解决方法(fāng fǎ)

从服务器上删除掉所有二进制日志文件包括一个数据(data)目录下master.info文件和hostname-relay-bin开头文件

master.info::记录(record)了Mysql主服务器上日志文件和记录(record)位置连接密码(code) 

 2出现错误(error)提示

 

Error reading packet from server: File ‘/home/mysql/mysqlLog/log.000001’ not found (Errcode: 2) ( server_errno=29)

解决方案:

由于主服务器运行了一段时间产生了二进制文件而slave是从log.000001开始读取删除主机二进制文件包括log.index文件

3错误(error)提示如下

 

Slave SQL: Error ‘Table ‘xxxx’ doesn’t exist’ on query. Default database: ‘t591’. Query: ‘INSERT INTO `xxxx`(type,post_id,browsenum) SELECT type,post_id,browsenum FROM xxxx WHERE hitdate=’20090209”, Error_code: 1146

解决方法(fāng fǎ)

由于slave没有此table表添加这个表使用slave start 就可以继续同步

 

4错误(error)提示如下

 

Error ‘Duplicate entry ‘1’ for key 1′ on query. Default database: ‘movivi1’. Query: ‘INSERT INTO `v1vid0_user_samename` VALUES(null,1,’123′,’11’,’4545′,’123′)’

 

 

Error ‘You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘ ‘ at line 1’ on query. Default database: ‘club’. Query: ‘INSERT INTO club.point_process ( GIVEID, GETID, POINT, CREATETIME, DEMO ) VALUES ( 0, 4971112, 5, ‘2010-12-19 16:29:28’, ‘

1 row in set (0.00 sec)

 Mysql > Slave statusG;

显示:Slave_SQL_Running 为 NO

解决方法(fāng fǎ):

Mysql > stop slave;

Mysql > set global sql_slave_skip_counter =1 ;

Mysql > start slave;

5错误(error)提示如下

# show slave statusG;

 

Master_Log_File: mysql-bin.000029

Read_Master_Log_Pos: 3154083

Relay_Log_File: c7-relay-bin.000178

Relay_Log_Pos: 633

Relay_Master_Log_File: mysql-bin.000025

Slave_IO_Running: Yes

Slave_SQL_Running: No

Replicate_Do_DB: club

Replicate_Ignore_DB: 

Replicate_Do_Table: 

Replicate_Ignore_Table: 

Replicate_Wild_Do_Table: 

Replicate_Wild_Ignore_Table: 

Last_Errno: 1594

Last_Error: Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master’s binary log is corrupted (you can check this by running ‘mysqlbinlog’ on the binary log), the slave’s relay log is corrupted (you can check this by running ‘mysqlbinlog’ on the relay log), a network problem, or a bug in the master’s or slave’s MySQL code. If you want to check the master’s binary log or slave’s relay log, you will be able to know their names by issuing ‘SHOW SLAVE STATUS’ on this slave.

Skip_Counter: 0

Exec_Master_Log_Pos: 1010663436

这个问题(problem)原因是主数据(data)库突然停止或问题(problem)终止更改了mysql-bin.xxx日志slave服务器找不到这个文件需要找到同步点和日志文件然后chage master即可

解决方法(fāng fǎ):

 

 change master to 

 master_host=’211.103.156.198′,

 master_user=’同步帐号’, 

 master_password=’同步密码(code)’, 

 master_port=3306, 

 master_log_file=’mysql-bin.000025‘, 

 master_log_pos=1010663436;

6错误(error)提示如下

 

Error ‘Unknown column ‘qdir’ in ‘field list” on query. Default database: ‘club’. Query: ‘insert into club.question_del (id, pid, ques_name, givepoint, title, subject, subject_pid, createtime, approve, did, status, intime, order_d, endtime,banzhu_uid,banzhu_uname,del_cause,qdir) select id, pid, ques_name, givepoint, title, subject, subject_pid, createtime, approve, did, status, intime, order_d, endtime,’1521859′,’admin0523′,’无意义回复’,qdir from club.question where id=7330212′

1 row in set (0.00 sec)

这个错误(error)就说club.question_del 表里面没有qdir这个字段 造成加上就可以了~

在主mysql : 里面查询 Desc club.question_del; 

在 错误(error)从服务器上执行 : alter table question_del add qdir varchar(30) not null;

该文章收集于互联网,如有侵权,请联系删除!

Performance Dashboard运行错误

Microsoft SQL Server 2005 Performance Dashboard Reports 是一组运行于 SQL Server 2005 SP2 Management Studio 及更高版本中的 Reporting Services 报表文件。他几乎统计了sql server 2005各个方面的报表,如cpu,内存,IO,未使用索引的查询等等,通过这些报表,SQL Server 用户可以更容易确定性能问题发生的时间以及可能存在的原因。这样可以更快地解决问题。

 

下载地址:

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=22602

 

今天运行 Performance Dashboard报了一个错,之前所有安装过程都是挺正常的,但执行“performance_dashboard_main.rdl”报表时出现“两个datetime 列的差别导致了运行时溢出。”错误。

解决办法:

1) 修改setup.sql脚本中的procedure MS_PerfDashboard.usp_Main_GetSessionInfo的内容中的“convert(bigint, datediff(ms, login_time, getdate()))”为“convert(bigint,datediff(dd,login_time,getdate()))*24*60*60*1000”

2) 将recent_cpu.rdl中的“convert(bigint, datediff(ms, login_time, getdate()))”都换成“convert(bigint,datediff(dd,login_time,getdate()))*24*60*60*1000”就可以了 

然后再执行setup.sql重新安装,再次运行Performance Dashboard,没有错误了。

 

 

关于mongodb 的日志轮询

mongod每天要产生大量的日志,如果不去管它,我这边一周大约有10~20G的日志出来,可见日志轮询是必须的。

mongodb本身支持日志轮询的信号,所以我的日志轮询脚本如下:

#!/bin/sh

log_dir="/var/log/mongo/"
killall -SIGUSR1 mongod
/usr/bin/find ${log_dir} -name ‘mongod.log.*’ -mtime +5  -exec rm -f {} ;

然后每天零点零分跑一下。

我有6台mongodb,上面的脚本跑了一两个月一直挺正常。但是最近其中一台在做日志轮询的时候可能是产生了死锁,因为我首先收到了读写锁过多的报警,日志轮询没有成功,客户端也连不进去。收到报警后就连到服务器去看,查查日志,确定问题后重启mongodb就正常了。

这个脚本造成服务中断14分钟,mongodb用的是最新的稳定版本1.8.1,mongodb的稳定性还有待提高。

 

发生这个问题之后,上面的脚本就不敢再用了,对脚本进行了更改:

#!/bin/sh

log_dir="/var/log/mongo/"
date=`date +%Y-%m-%d`

cat ${log_dir}/mongod.log >> ${log_dir}/mongod.log.${date}
cat /dev/null > ${log_dir}/mongod.log

/usr/bin/find ${log_dir} -name ‘mongod.log.*’ -mtime +5  -exec rm -f {} ;

然后让他一小时跑一次,目前看还行,就是要多占一点磁盘IO,但是稳定第一,可以确保不会出现上面的问题了。

 

mysql 二进制日志轮询及innodb的写优化

innodb_buffer_pool_size
如果用Innodb,那么这是一个重要变量。相对于MyISAM来说,Innodb对于buffer size更敏感。MySIAM可能对于大数据量使用默认的key_buffer_size也还好,但Innodb在大数据量时用默认值就感觉在爬了。 Innodb的缓冲池会缓存数据和索引,所以不需要给系统的缓存留空间,如果只用Innodb,可以把这个值设为内存的70%-80%。和 key_buffer相同,如果数据量比较小也不怎么增加,那么不要把这个值设太高也可以提高内存的使用率。

innodb_additional_pool_size
这个的效果不是很明显,至少是当操作系统能合理分配内存时。但你可能仍需要设成20M或更多一点以看Innodb会分配多少内存做其他用途。

innodb_log_file_size
对于写很多尤其是大数据量时非常重要。要注意,大的文件提供更高的性能,但数据库恢复时会用更多的时间。我一般用64M-512M,具体取决于服务器的空间。

innodb_log_buffer_size
默认值对于多数中等写操作和事务短的运用都是可以的。如果经常做更新或者使用了很多blob数据,应该增大这个值。但太大了也是浪费内存,因为1秒钟总会 flush(这个词的中文怎么说呢?)一次,所以不需要设到超过1秒的需求。8M-16M一般应该够了。小的运用可以设更小一点。

innodb_flush_log_at_trx_commit  (这个很管用)
抱怨Innodb比MyISAM慢 100倍?那么你大概是忘了调整这个值。默认值1的意思是每一次事务提交或事务外的指令都需要把日志写入(flush)硬盘,这是很费时的。特别是使用电池供电缓存(Battery backed up cache)时。设成2对于很多运用,特别是从MyISAM表转过来的是可以的,它的意思是不写入硬盘而是写入系统缓存。日志仍然会每秒flush到硬盘,所以你一般不会丢失超过1-2秒的更新。设成0会更快一点,但安全方面比较差,即使MySQL挂了也可能会丢失事务的数据。而值2只会在整个操作系统挂了时才可能丢数据。

 

上面是网上看的,我发现慢查询日志内有很多update和insert的查询,就把innodb_flush_log_at_trx_commit改成了2,效果很明显,改成0会更明显,但安全性比较差。做下面的操作启动mysqld就生效:

vim /etc/my.cnf

innodb_flush_log_at_trx_commit=2

 

也可以在mysqld运行时执行:

set GLOBAL innodb_flush_log_at_trx_commit = 2

 

下面是mysql手册上innodb_flush_log_at_trx_commit的解释:

如果innodb_flush_log_at_trx_commit设置为0,log buffer将每秒一次地写入log file中,并且log file的flush(刷到磁盘)操作同时进行;但是,这种模式下,在事务提交的时候,不会有任何动作。如果innodb_flush_log_at_trx_commit设置为1(默认值),log buffer每次事务提交都会写入log file,并且,flush刷到磁盘中去。如果innodb_flush_log_at_trx_commit设置为2,log buffer在每次事务提交的时候都会写入log file,但是,flush(刷到磁盘)操作并不会同时进行。这种模式下,MySQL会每秒一次地去做flush(刷到磁盘)操作。注意:由于进程调度策略问题,这个“每秒一次的flush(刷到磁盘)操作”并不是保证100%的“每秒”。

默认值1是为了ACID (atomicity, consistency, isolation, durability)原子性,一致性,隔离性和持久化的考虑。如果你不把innodb_flush_log_at_trx_commit设置为1,你将获得更好的性能,但是,你在系统崩溃的情况,可能会丢失最多一秒钟的事务数据。当你把innodb_flush_log_at_trx_commit设置为0,mysqld进程的崩溃会导致上一秒钟所有事务数据的丢失。如果你把innodb_flush_log_at_trx_commit设置为2,只有在操作系统崩溃或者系统掉电的情况下,上一秒钟所有事务数据才可能丢失。InnoDB的crash recovery崩溃恢复机制并不受这个值的影响,不管这个值设置为多少,crash recovery崩溃恢复机制都会工作。

 

 

另外innodb_flush_method参数也值得关注,对写操作有影响:

innodb_flush_method: 设置InnoDB同步IO的方式:

   1) Default – 使用fsync()。
   2) O_SYNC 以sync模式打开文件,通常比较慢。
   3) O_DIRECT,在Linux上使用Direct IO。可以显著提高速度,特别是在RAID系统上。避免额外的数据复制和double buffering(mysql buffering 和OS buffering)。

 

mysql二进制轮询的问题:

vi /etc/my.cnf

expire-logs-days = 7

这样mysql就自动会删除超过7天的二进制日志了。

手动删除可以用PURGE MASTER LOGS,下面也是网上看到的:

PURGE MASTER LOGS语法
PURGE {MASTER | BINARY} LOGS TO ‘log_name’
PURGE {MASTER | BINARY} LOGS BEFORE ‘date’
用于删除列于在指定的日志或日期之前的日志索引中的所有二进制日志。这些日志也会从记录在日志索引文件中的清单中被删除,这样被给定的日志成为第一个。
例如:
PURGE MASTER LOGS TO ‘mysql-bin.010’;
PURGE MASTER LOGS BEFORE ‘2003-04-02 22:46:26’;
BEFORE变量的date自变量可以为’YYYY-MM-DD hh:mm:ss’格式。MASTER和BINARY是同义词。
如果您有一个活性的从属服务器,该服务器当前正在读取您正在试图删除的日志之一,则本语句不会起作用,而是会失败,并伴随一个错误。不过,如果从属服务器是休止的,并且您碰巧清理了其想要读取的日志之一,则从属服务器启动后不能复制。当从属服务器正在复制时,本语句可以安全运行。