转载自http://www.perfgeeks.com/?p=365

优化MySQL最重要的一部分工作是先确定”有问题”的查询语句。只有先找出这些查询较慢的sql查询(执行时间较长)，我们才能进一步分析原因并且优化它。MySQL为我们提供了Slow Query Log记录功能，它能记录执行时间超过了特定时长的查询。分析Slow Query Log有助于帮我们找到”问题”查询。

记录slow queries

首先，我们需要查看mysql server版本号，以及是否配置启用了slow query log。查看mysql server版本号，主要是一些功能以及配置依赖于mysql server 版本号
查看mysql server版本号

$echo "status" |mysql |grep "Server version"
Server version:         5.1.38-log Source distribution

不同的MySQL版本，设定与功能略有不同。
检查当前服务器有没有在记录slow query

$mysqladmin var |grep "log_slow" |tr -d "|"
log_slow_queries	OFF

当log_slow_queries是ON时，才表示已经启用了记录slow query功能。默认是不记录slow query的。
启用slow query日志

#//将下列配置放到my.cnf中，查看my.cnf位置可以使用命令ps -ef |grep mysqld_safe
[mysqld]
log-slow-queries	= /var/lib/mysql/slow-queries.log
long_query_time		= 1
log-queries-not-using-indexes
log-slow-admin-statements

上面的配置打开了slow query日志,将会捕获了执行时间超过了1秒的查询，包括执行速度较慢的管理命令(比如OPTIMEZE TABLE),并且记录了没有使用索引的查询。这些SQL，都会被记录到log-slow-queries指定的文件/var/lib/mysql/slow-queries.log文件中。

log-slow-queries <slow_query_log_file>
存放slow query日志的文件。你必须保证mysql server进程mysqld_safe进程用户对该文件有w权限。
long_query_time
如果query time超过了该值，则认为是较慢查询，并被记录下来。单位是秒，最小值是1,默认值是10秒。10秒对于大多数应用来讲，太长了。我们推荐从3秒开始，依次减少，每次都找出最”昂贵”的10条SQL语句并且优化他们。日复一日，一步一步优化。一次性找出很多条SQL语句，对于优化来讲，意义并不大。
log-queries-not-using-indexes
MySQL会将没有使用索引的查询记录到slow query日志中。无论它执行有多快，查询语句没有使用索引，都会被记录。有的时候，有些没有使用引索的查询非常快(例如扫描很小的表)，但也有可能导致服务器变慢，甚至还会使用大量的磁盘空间。
log-slow-admin-statements
一些管理指令，也会被记录。比如OPTIMEZE TABLE, ALTER TABLE等等。

日志文件

我们可以通过tail -f查看日志文件。

$tail -f /var/lib/mysql/slow-queries.log
# Time: 110107 16:22:11
# User@Host: root[root] @ localhost []
# Query_time: 9.869362  Lock_time: 0.000035 Rows_sent: 1  Rows_examined: 6261774
SET timestamp=1294388531;
select count(*) from ep_friends;

第一行,SQL查询执行的时间
第二行,执行SQL查询的连接信息
第三行记录了一些我们比较有用的信息
    Query_time SQL执行的时间,越长则越慢
    Lock_time 在MySQL服务器阶段(不是在存储引擎阶段)等待表锁时间
    Rows_sent 查询返回的行数
    Rows_examined 查询检查的行数
Slow Query日志，虽然帮助你记录了那些执行过了的SQL语句。但它不是万能的，意义可能没有你想象的那么大。它只告诉了你哪些语句慢，但是为什么慢?具体原因，还是需要你自己去分析，不断的调试。也许，你只需要换一条更有效的sql语句，也许你只需简单地增加一个索引，但也有可能你需要调整你应用程序的设计方案。比如，上面那条语句是很明显，它检查了600多万行数据。不幸的是，并不是每条语句都这么明显。也许还有别的原因，比如:
*锁表了，导致查询处于等态状态。lock_time显示了查询等待锁被翻译的时间
*数据或索引没有被缓存。常见于第一次启动服务器或者服务器没有调优
*备份数据库，I/O变慢
*也许同时运行了其它的查询，减少了当前查询

所以,不要过于紧张日志文件某条记录，而应该理性地审记，找出真正的原因。如果经常出现的slow query需要特别注意。如果个别出现，则做一些常规检查即可。我们建议，统计并且形成基准报告，进行比较排除，比胡乱瞎撞有用。希望大家不要在这部分过于浪费时间与精力。

线上记录slow query

上文的配置需要重启mysql server进程mysqld才会生效。但是很多时候，尤其是产品运营环境，不希望每次修改都需要重新启动mysql服务器，也希望能在某些特定时间记录。MySQL5.1给我们提供了更为灵活的运行时控制，使得你不必重新启动mysql服务器，也能选择性地记录或者不记录某些slow queries。

MySQL5.1中，提供了全局变量slow_query_log、slow_query_log_file可以灵活地控制enable/disable慢查询。同时可以通过long_query_time设置时间

#//停用slow query记录
#注意:设置了slow_query_log全局变量, log_slow_queries也会隐性地跟着改变
mysql>set global slow_query_log=OFF

不幸运的是,在MySQL5.0并没有提供类似的全局变量来灵活控制，但是我们可以通过将long_query_time设置得足够大来避免记录某些查询语句。比如

MySQL5.0, 不关服务的情况下，希望不记录日志的办法是将日志文件成为/dev/null的符号链接(symbolic link)。注意:你只需要在改变后运行FLUSH LOGS以确定MYSQL释放当前的日志文件描述符，重新把日志记录到/dev/null

和MySQL5.0不同,MySQL5.1可以在运行时改变日记行为，将日志记录到数据库表中。只要将mysql全局变量log_output设置为TABLE即可。MySQL会将日志分别记录到表mysql.gengera_log和mysql.slow_log二张表中。但是，我们推荐将日志记录在日记文件中。

缺陷与审记

虽然记录了slow query能够帮助你优化产品。但是MySQL目前版本，还有几大蹩足的地方。
1.MySQL5.0版本, long_query_time时间粒度不够细,最小值为1秒。对于高并发性能的网页脚本而言，1秒出现的意义不大。即出现1秒的查询比较少。直到mysql5.1.21才提供更细粒度的long_query_time设定.
2.不能将服务器执行的所有查询记录到慢速日志中。虽然MySQL普通日志记录了所有查询，但是它们是解析查询之前就记录下来了。这意味着普通日志没办法包含诸如执行时间，锁表时间，检查行数等信息。
3.如果开启了log_queries_not_using_indexes选项，slow query日志会充满过多的垃圾日志记录，这些快且高效的全表扫描查询(表小)会冲掉真正有用的slow queries记录。比如select * from category这样的查询也会被记录下来。

通过microslow-patch补丁可使用更细的时间粒度，和记录所有执行过的sql语句。不过，使用这个补订不得不自己编译MySQL，出于稳定性考滤，我们推荐在开发测试环境，可以打上这个补丁，享受这个补丁带来的便利。在运营环境尽量不要这么做…

MySQL自带了mysqldumpslow工具用来分析slow query日志，除此之外，还有一些好用的开源工具。比如MyProfi、mysql-log-filter，当然还有mysqlsla

Related posts:

1. MySQL5.5复制/同步的新特性及改进
2. MySQL Replication基本原理
3. PIX logging Architecture所需perl module的几点注意

magent是一款开源的Memcached代理服务器软件，可以用它做一些高可用尝试。

一、安装步骤：
1、编译安装libevent：
wget http://monkey.org/~provos/libevent-1.4.9-stable.tar.gz
tar zxvf libevent-1.4.9-stable.tar.gz
cd libevent-1.4.9-stable/
./configure –prefix=/usr
make && make install
cd ../

2、编译安装Memcached：
wget http://danga.com/memcached/dist/memcached-1.2.6.tar.gz
tar zxvf memcached-1.2.6.tar.gz
cd memcached-1.2.6/
./configure –with-libevent=/usr
make && make install
cd ../

3、编译安装magent：
mkdir magent
cd magent/
wget http://memagent.googlecode.com/files/magent-0.5.tar.gz
tar zxvf magent-0.5.tar.gz
/sbin/ldconfig
sed -i “s#LIBS = -levent#LIBS = -levent -lm#g” Makefile
make
cp magent /usr/bin/magent
cd ../

二、高可用网络架构

服务器A                                                                   服务器B

启动两个memcached进程，端口分别为11211和11212：
memcached -m 1 -u root -d -l 127.0.0.1 -p 11211
memcached -m 1 -u root -d -l 127.0.0.1 -p 11212

启动两个magent进程，端口分别为10000和11000：
magent -u root -n 51200 -l 127.0.0.1 -p 10000 -s 127.0.0.1:11211 -b 127.0.0.1:11212
magent -u root -n 51200 -l 127.0.0.1 -p 11000 -s 127.0.0.1:11212 -b 127.0.0.1:11211
-s 为要写入的memcached， -b 为备份用的memcached。
说明：测试环境用magent和memached的不同端口来实现，在生产环境中可以将magent和memached作为一组放到两台服务器上。

也就是说通过magent能够写入两个memcached。
[root@odb ~]# telnet 127.0.0.1 10000
Trying 127.0.0.1…
Connected to localhost.localdomain (127.0.0.1).
Escape character is ‘^]’.
set key 0 0 8                       <—在10000端口设置key的值
88888888
STORED
quit
Connection closed by foreign host.
[root@odb ~]# telnet 127.0.0.1 11211
Trying 127.0.0.1…
Connected to localhost.localdomain (127.0.0.1).
Escape character is ‘^]’.
get key                     <—在11211端口获取key的值成功
VALUE key 0 8
88888888
END
quit
Connection closed by foreign host.
[root@odb ~]# telnet 127.0.0.1 11212
Trying 127.0.0.1…
Connected to localhost.localdomain (127.0.0.1).
Escape character is ‘^]’.
get key                     <—在11212端口获取key的值成功
VALUE key 0 8
88888888
END
quit
Connection closed by foreign host.

高可用性测试：
[root@odb ~]# ps aux |grep -v grep |grep memcached
root     23455  0.0  0.0  5012 1796 ?        Ss   09:22   0:00 memcached -m 1 -u root -d -l 127.0.0.1 -p 11212
root     24950  0.0  0.0  4120 1800 ?        Ss   10:58   0:00 memcached -m 1 -u root -d -l 127.0.0.1 -p 11211
[root@odb ~]# ps aux |grep -v grep |grep ‘magent -u’
root     25919  0.0  0.0  2176  484 ?        Ss   12:00   0:00 magent -u root -n 51200 -l 127.0.0.1 -p 10000 -s 127.0.0.1:11211 -b 127.0.0.1:11212
root     25925  0.0  0.0  3004  484 ?        Ss   12:00   0:00 magent -u root -n 51200 -l 127.0.0.1 -p 11000 -s 127.0.0.1:11212 -b 127.0.0.1:11211
[root@odb ~]# telnet 127.0.0.1 10000
Trying 127.0.0.1…
Connected to localhost.localdomain (127.0.0.1).
Escape character is ‘^]’.
set stone 0 0 6                      <—在10000端口设置stone的值
123456
STORED
quit
Connection closed by foreign host.
[root@odb ~]# telnet 127.0.0.1 11000
Trying 127.0.0.1…
Connected to localhost.localdomain (127.0.0.1).
Escape character is ‘^]’.
set shidl 0 0 6                      <—在11000端口设置shidl的值
666666
STORED
get stone                      <—在11000端口获取stone的值成功
VALUE stone 0 6
123456
END
incr stone 2                      <—在11000端口修改stone的值成功
123458
get stone
VALUE stone 0 6                     <—在11000端口验证stone的值，证明上面的修改成功
123458
END
get shidl                      <—在11000端口获取shidl的值成功
VALUE shidl 0 6
666666
END
quit                     <—退出11000端口
Connection closed by foreign host.
[root@odb ~]# telnet 127.0.0.1 10000
Trying 127.0.0.1…
Connected to localhost.localdomain (127.0.0.1).
Escape character is ‘^]’.
get stone                      <—在10000端口获取stone的值，已被修改
VALUE stone 0 6
123458
END
get shidl                      <—在10000端口获取shidl的值成功
VALUE shidl 0 6
666666
END
delete shidl                      <—在10000端口删除shidl
DELETED
get shidl                      <—在10000端口删除shidl生效
END
quit
Connection closed by foreign host.
[root@odb ~]# telnet 127.0.0.1 11000
Trying 127.0.0.1…
Connected to localhost.localdomain (127.0.0.1).
Escape character is ‘^]’.
get shidl                      <—在11000端口验证删除shidl生效
END
get stone                      <—在11000端口获取stone的值成功
VALUE stone 0 6
123458
END
quit
Connection closed by foreign host.

Down机模拟测试：

Down掉11211端口的memcached：

[root@odb ~]# kill -9 24950
[root@odb ~]# telnet 127.0.0.1 10000
Trying 127.0.0.1…
Connected to localhost.localdomain (127.0.0.1).
Escape character is ‘^]’.
get stone                      <—在10000依然可以获取stone的值
VALUE stone 0 6
123458
END
quit
Connection closed by foreign host.
[root@odb ~]# telnet 127.0.0.1 11000
Trying 127.0.0.1…
Connected to localhost.localdomain (127.0.0.1).
Escape character is ‘^]’.
get stone                      <—在11000依然可以获取stone的值
VALUE stone 0 6
123458
END
quit
Connection closed by foreign host.

Down掉11000端口的magent：

[root@odb ~]# kill -9 25925
[root@odb ~]# telnet 127.0.0.1 10000
Trying 127.0.0.1…
Connected to localhost.localdomain (127.0.0.1).
Escape character is ‘^]’.
get stone                      <—在10000依然可以获取stone的值
VALUE stone 0 6
123458
END
quit
Connection closed by foreign host.

标签: ha, memcached

Related posts:

1. vmware server 2.0 安装要点
2. Apache2与Resin2整合虚拟主机的配置
3. 系统安全笔记

MySQL5.5的在复制/同步方面的改进：

    * 保证主从服务器上数据的一致性（同步）
    * 能立检测到复制的异常
    * Crashed Salve能自动从错误中恢复同步
    * 在环形复制中用户能够指定跳过某实例事件
    * 主从复制中能自动适应字段类型的转换

MySQL半同步复制(semi-synchronous replication)

默认情况下MySQL的复制是异步的，Master上所有的更新操作写入Binlog之后并不确保所有的更新都被复制到Slave之上。异步操作虽然效率高，但是在Master/Slave出现问题的时候，存在很高数据不同步的风险，甚至可能丢失数据。

MySQL5.5引入半同步复制功能的目的是为了保证在master出问题的时候，至少有一台Slave的数据是完整的。在超时的情况下也可以临时转入异步复制，保障业务的正常使用，直到一台salve追赶上之后，继续切换到半同步模式。

Master:
INSTALL PLUGIN ‘rpl_semi_sync_master’ SONAME ‘semisync_master.so’;
SET GLOBAL rpl_semi_sync_master_enabled=1;
SET GLOBAL rpl_semi_sync_master_timeout=1000; (1s, default 10s)

Slave:
INSTALL PLUGIN ‘rpl_semi_sync_slave’ SONAME ‘semisync_slave.so’;
SET GLOBAL rpl_semi_sync_slave_enabled=1;

默认情况下MySQL的复制是异步的，Master上所有的更新操作写入Binlog之后并不确保所有的更新都被复制到Slave之上。异步操作虽然效率高，但是在Master/Slave出现问题的时候，存在很高数据不同步的风险，甚至可能丢失数据。

MySQL5.5引入半同步复制功能的目的是为了保证在master出问题的时候，至少有一台Slave的数据是完整的。在超时的情况下也可以临时转入异步复制，保障业务的正常使用，直到一台salve追赶上之后，继续切换到半同步模式。

Master:
INSTALL PLUGIN ‘rpl_semi_sync_master’ SONAME ‘semisync_master.so’;
SET GLOBAL rpl_semi_sync_master_enabled=1;
SET GLOBAL rpl_semi_sync_master_timeout=1000; (1s, default 10s)

Slave:
INSTALL PLUGIN ‘rpl_semi_sync_slave’ SONAME ‘semisync_slave.so’;
SET GLOBAL rpl_semi_sync_slave_enabled=1;

复制心跳（用户检测复制是否中断）

MySQL5.5提供的新的配置master_heartbeat_period，能够在复制停止工作和出现网络中断的时候帮助我们迅速发现问题。

启用方法：

STOP SLAVE;
CHANGE MASTER TO master_heartbeat_period= milliseconds;
START SLAVE;

Slave自动恢复同步

在MySQL5.5版本之前，MySQL Slave实例在异常终止服务之后，可能导致复制中断，并且relay binlog可能损坏，在MySQL再次启动之后并不能正常恢复复制。在MySQL5.5中这一问题得到了解决，MySQL可以自行丢弃顺坏的而未处理的数据，重新从master上获取源数据，进而回复复制。

跳过指定复制事件

在多Master或环形复制的情况下，处于复制链条中间的服务器异常，可以通过

CHANGE MASTER TO MASTER_HOST=xxx IGNORE_SERVER_IDS=y

跳过出问题的MySQL实例。

自动转换字段类型

MySQL5.1在基于语句的复制下，支持部分的字段转换，但是行级的会报错。MySQL5.5语句和行级复制都已支持。还可以通过 SLAVE_TYPE_CONVERSIONS 控制转换的方向。

标签: mysql, replication, 5.5

Related posts:

1. MySQL Slow Query
2. MySQL Replication基本原理
3. Mysql导入慢的解决方法

    Mysql的复制（replication）是一个异步的复制，从一个Mysql instace（称之为Master）复制到另一个Mysql instance（称之Slave）。实现整个复制操作主要由三个进程完成的，其中两个进程在Slave（Sql进程和IO进程），另外一个进程在Master（IO进程）上。

    要实施复制，首先必须打开Master端的binary log（bin-log）功能，否则无法实现。因为整个复制过程实际上就是Slave从Master端获取该日志然后再在自己身上完全顺序的执行日志中所记录的各种操作。

    复制的基本过程如下：

    1)、Slave上面的IO进程连接上Master，并请求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容；

    2)、Master接收到来自Slave的IO进程的请求后，通过负责复制的IO进程根据请求信息读取制定日志指定位置之后的日志信息，返回给Slave的IO进程。返回信息中除了日志所包含的信息之外，还包括本次返回的信息已经到Master端的bin-log文件的名称以及bin-log的位置；

    3)、Slave的IO进程接收到信息后，将接收到的日志内容依次添加到Slave端的relay-log文件的最末端，并将读取到的Master端的bin-log的文件名和位置记录到master-info文件中，以便在下一次读取的时候能够清楚的高速Master“我需要从某个bin-log的哪个位置开始往后的日志内容，请发给我”；

    4)、Slave的Sql进程检测到relay-log中新增加了内容后，会马上解析relay-log的内容成为在Master端真实执行时候的那些可执行的内容，并在自身执行。

    实际上在老版本的Mysql的复制实现在Slave端并不是两个进程完成的，而是由一个进程完成。但是后来发现这样做存在较大的风险和性能问题，主要如下：

    首先，一个进程就使复制bin-log日志和解析日志并在自身执行的过程成为一个串行的过程，性能受到了一定的限制，异步复制的延迟也会比较长。

    另外，Slave端从Master端获取bin-log过来之后，需要接着解析日志内容，然后在自身执行。在这个过程中，Master端可能又产生了大量变化并声称了大量的日志。如果在这个阶段Master端的存储出现了无法修复的错误，那么在这个阶段所产生的所有变更都将永远无法找回。如果在Slave端的压力比较大的时候，这个过程的时间可能会比较长。

    所以，后面版本的Mysql为了解决这个风险并提高复制的性能，将Slave端的复制改为两个进程来完成。提出这个改进方案的人是Yahoo!的一位工程师“Jeremy Zawodny”。这样既解决了性能问题，又缩短了异步的延时时间，同时也减少了可能存在的数据丢失量。当然，即使是换成了现在这样两个线程处理以后，同样也还是存在slave数据延时以及数据丢失的可能性的，毕竟这个复制是异步的。只要数据的更改不是在一个事物中，这些问题都是会存在的。如果要完全避免这些问题，就只能用mysql的cluster来解决了。不过mysql的cluster是内存数据库的解决方案，需要将所有数据都load到内存中，这样就对内存的要求就非常大了，对于一般的应用来说可实施性不是太大。

    2、复制实现级别

    Mysql的复制可以是基于一条语句（Statement level），也可以是基于一条记录（Row level），可以在Mysql的配置参数中设定这个复制级别，不同复制级别的设置会影响到Master端的bin-log记录成不同的形式。

    Row Level：日志中会记录成每一行数据被修改的形式，然后在slave端再对相同的数据进行修改。

    优点：在row level模式下，bin-log中可以不记录执行的sql语句的上下文相关的信息，仅仅只需要记录那一条记录被修改了，修改成什么样了。所以row level的日志内容会非常清楚的记录下每一行数据修改的细节，非常容易理解。而且不会出现某些特定情况下的存储过程，或function，以及trigger的调用和触发无法被正确复制的问题。

    缺点：row level下，所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容，比如有这样一条update语句：update product set owner_member_id = ‘b’ where owner_member_id = ‘a’，执行之后，日志中记录的不是这条update语句所对应额事件（mysql以事件的形式来记录bin-log日志），而是这条语句所更新的每一条记录的变化情况，这样就记录成很多条记录被更新的很多个事件。自然，bin-log日志的量就会很大。尤其是当执行alter table之类的语句的时候，产生的日志量是惊人的。因为Mysql对于alter table之类的表结构变更语句的处理方式是整个表的每一条记录都需要变动，实际上就是重建了整个表。那么该表的每一条记录都会被记录到日志中。

    Statement Level:每一条会修改数据的sql都会记录到 master的bin-log中。slave在复制的时候sql进程会解析成和原来master端执行过的相同的sql来再次执行。

    优点：statement level下的优点首先就是解决了row level下的缺点，不需要记录每一行数据的变化，减少bin-log日志量，节约IO，提高性能。因为他只需要记录在Master上所执行的语句的细节，以及执行语句时候的上下文的信息。

    缺点：由于他是记录的执行语句，所以，为了让这些语句在slave端也能正确执行，那么他还必须记录每条语句在执行的时候的一些相关信息，也就是上下文信息，以保证所有语句在slave端杯执行的时候能够得到和在master端执行时候相同的结果。另外就是，由于Mysql现在发展比较快，很多的新功能不断的加入，使mysql得复制遇到了不小的挑战，自然复制的时候涉及到越复杂的内容，bug也就越容易出现。在statement level下，目前已经发现的就有不少情况会造成mysql的复制出现问题，主要是修改数据的时候使用了某些特定的函数或者功能的时候会出现，比如：sleep()函数在有些版本中就不能真确复制，在存储过程中使用了last_insert_id()函数，可能会使slave和master上得到不一致的id等等。由于row level是基于每一行来记录的变化，所以不会出现类似的问题。

    从官方文档中看到，之前的Mysql一直都只有基于statement的复制模式，直到5.1.5版本的Mysql才开始支持row level的复制。从5.0开始，Mysql的复制已经解决了大量老版本中出现的无法正确复制的问题。但是由于存储过程的出现，给Mysql的复制又带来了更大的新挑战。另外，看到官方文档说，从5.1.8版本开始，Mysql提供了除Statement Level和Row Level之外的第三种复制模式：Mixed，实际上就是前两种模式的结合。

    在Mixed模式下，Mysql会根据执行的每一条具体的sql语句来区分对待记录的日志形式，也就是在Statement和Row之间选择一种。新版本中的Statment level还是和以前一样，仅仅记录执行的语句。而新版本的Mysql中队row level模式也被做了优化，并不是所有的修改都会以row level来记录，像遇到表结构变更的时候就会以statement模式来记录，如果sql语句确实就是update或者delete等修改数据的语句，那么还是会记录所有行的变更。

    3、复制常用架构

    Mysql复制环境90%以上都是一个Master带一个或者多个Slave的架构模式，主要用于读压力比较大的应用的数据库端廉价扩展解决方案。因为只要master和slave的压力不是太大（尤其是slave端压力）的话，异步复制的延时一般都很少很少。尤其是自slave端的复制方式改成两个进程处理之后，更是减小了slave端的延时。而带来的效益是，对于数据实时性要求不是特别的敏感度的应用，只需要通过廉价的pc server来扩展slave的数量，将读压力分散到多台slave的机器上面，即可解决数据库端的读压力瓶颈。这在很大程度上解决了目前很多中小型网站的数据库压力瓶颈问题，甚至有些大型网站也在使用类似方案解决数据库瓶颈。

    一个Master带多个slave的架构实施非常简单，多个slave和单个slave的实施并没有太大区别。在Master端并不care有多少个slave连上了master端，只要有slave进程通过了连接认证，向他请求binlog信息，他就会按照连接上来的io进程的要求，读取自己的binlog信息，返回给slave的IO进程。对于slave的配置细节，在Mysql的官方文档上面已经说的很清楚了，甚至介绍了多种实现slave的配置方法。

    Mysql不支持一个Slave instance从属于多个Master的架构。就是说，一个slave instance只能接受一个master的同步源，听说有patch可以改进这样的功能，但没有实践过。Mysql AB之所以不实现这样的功能，主要是考虑到冲突解决的问题。

    Mysql也可以搭建成dual master模式，也就是说两个Mysql instance互为对方的Master，也同时为对方的Slave。不过一般这种架构也是只有一端提供服务，避免冲突问题。因为即使在两边执行的修改有先后顺序，由于复制的异步实现机制，同样会导致即使在晚做的修改也可能会被早做的修改所覆盖，就像如下情形：

    时间点 Mysql A Mysql B
    1        更新x表y记录为10
    2        更新x表y记录为20
    3        获取到A日志并应用，更新x表的y记录为10（不符合期望）
    4        获取B日志更新x表y记录为20（符合期望）

    这样，不仅在B库上面的数据不是用户所期望的结果，A和B两边的数据也出现了不一致的情况。除非能将写操作根据某种条件固定分开在A和B两端，保证不会交叉写入，才能够避免上面的问题。

标签: mysql, replication, master, slave, 原理, ha

Related posts:

1. MySQL Slow Query
2. MySQL5.5复制/同步的新特性及改进
3. Mysql导入慢的解决方法

#!/bin/sh

if [ $# -ne 1 ] ;
then
echo "Usage: $0 <Username>";
echo "WARNING: the <Username> MUST in upper case.";
exit 1;
fi

username=$1
echo $username

function_get_info(){
username=$1

sqlplus  / as sysdba  <<EOF
select username,sid,serial# from v\$session where username = '$username';
EXIT
EOF
}

function_get_info ${username} |awk '/^'${username}'/ { print "alter system kill session '\''"  $2 "," $3 "'\'' ; "} '
sql_killsession=`function_get_info |awk '/^'${username}'/ { print "alter system kill session  '\''"  $2 "," $3 "'\''; "} '`
echo $sql_killsession

sqlplus  / as sysdba  <<EOF
#$sql_killsession
EXIT
EOF

标签: oracle, killsession

Related posts:

1. 笔记：查询oracle被锁的对象
2. 如何使用跟踪事件10046
3. AutoTrace

2、启用外键约束的命令为：alter table table_name enable constraint constraint_name

3、禁用外键约束的命令为：alter table table_name disable constraint constraint_name

4、然后再用SQL查出数据库中所以外键的约束名：

select 'alter table '||table_name||' enable constraint '||constraint_name||';' from user_constraints where constraint_type='R'

select 'alter table '||table_name||' disable constraint '||constraint_name||';' from user_constraints where constraint_type='R'

Related posts:

1. oralce10g shrink
2. drop table遭遇ORA-604 / ORA-1422
3. Oracle9i优化器介绍（下）

此表保存了“股票”与“研究员”的对应关系数据，一般而言，对于同一只股票而言，可能有多个研究员对其进行跟踪研究。所以目前遇到一个要求，需查询出每只股票和对应的研究员（研究员代码间，使用逗号分隔）。

例如有如下数据：
000297                                    chenpeng           
000297                                    liusu             
合并处理后需显示为：
000297                                    chenpeng,liusu

多行数据汇总聚一行，只需要把SQL中“n_sec_code”换为你的用来汇总的列，“c_researcher_code”替换为需合并文本的列，“m_researcher_stock_rel”替换为你的表名

 SELECT n_sec_code,
  TRANSLATE (LTRIM (text, '/'), '*/', '*,') researcherList
   FROM
  (SELECT ROW_NUMBER () OVER (PARTITION BY n_sec_code ORDER BY n_sec_code, lvl DESC) rn,
    n_sec_code                                                                         ,
    text
     FROM
    (SELECT n_sec_code,
      LEVEL lvl       ,
      SYS_CONNECT_BY_PATH (c_researcher_code,'/') text
       FROM
      (SELECT n_sec_code                      ,
        c_researcher_code AS c_researcher_code,
        ROW_NUMBER () OVER (PARTITION BY n_sec_code ORDER BY n_sec_code,c_researcher_code) x
         FROM m_researcher_stock_rel
     ORDER BY n_sec_code,
        c_researcher_code
      ) a CONNECT BY n_sec_code = PRIOR n_sec_code
    AND x - 1                   = PRIOR x
    )
  )
  WHERE rn = 1
ORDER BY n_sec_code;

Related posts:

1. sqlplus下如何看执行计划
2. Oracle分析函数参考手册
3. Statistics Lock导致的IMP问题

SQLSTATE[HY000]: General error: 1366 Incorrect integer value: 'log' for column 'tasklog_id' at row 1

这是因为mysql5.5中默认启用了STRICT_TRANS_TABLES参数。

STRICT_TRANS_TABLES的工作方式：
　　· 对于事务性存储引擎，在语句中任何地方出现的不良数据值均会导致放弃语句并执行回滚。
        · 对于非事务性存储引擎，如果错误出现在要插入或更新的第1行，将放弃语句。（在这种情况下，可以认为语句未改变表，就像事务表一样）。首行后出现的错误不会导致放弃语句。取而代之的是，将调整不良数据值，并给出告警，而不是错误。换句话讲，使用STRICT_TRANS_TABLES后，错误值会导致MySQL执行回滚操作，如果可以，所有更新到此为止。

　　要想执行更严格的检查，请启用STRICT_ALL_TABLES。除了非事务性存储引擎，它与STRICT_TRANS_TABLES等同，即使当不良数据出现在首行后的其他行，所产生的错误也会导致放弃语句。这意味着，如果错误出现在非事务性表多行插入或更新过程的中途，仅更新部分结果。前面的行将完成插入或更新，但错误出现点后面的行则不然。

因此，解决方法就是在my.ini里把STRICT_TRANS_TABLES关掉

#Set the SQL mode to strict
#sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
sql-mode="NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"

No related posts.

相关参考信息:

• Oracle Trace: The Swiss Army Knife of Diagnostic Tools
• Setting Events
• Trace and TKPROF

Related posts:

1. ORACLE STATSPACK REPORT输出结果说明
2. 禁用/启用所有外键约束
3. Oracle 10g 手动建库

sqlplus可以与vi整合，在sqlplus中调用vi编辑器。方法是在sqlplus中执行define_editor='vi'，或将define_editor='vi'添加到/product/10.2/sqlplus/admin/glogin.sql文件中。

之后再登录sqlplus，可以输入edit命令编辑上一次执行的sql。

更人性化的提示符

在glogin.sql文件中添加：

set termout off
default gname=idle
column global_name new_value gname
SELECT lower(USER) || '@' ||upper(instance_name)||'('||nvl(UTL_INADDR.GET_HOST_ADDRESS, SYS_CONTEXT('userenv', 'ip_address'))||')' GLOBAL_NAME FROM v$instance;
set sqlprompt '&gname> '
set termout on

这样每次登录SQLPLUS提示符会自动更改为“当前用户名@实例名(IP地址)> ”的形式。

10g以下版本在登录后切换用户的情况下，提示符不能自动更新。

No related posts.