发表于 | 分类于 | 阅读次数
阅读时长 1

查询数据库中的存储过程

方法一：
selectnamefrom mysql.proc where db = 'your_db_name' andtype= 'PROCEDURE';

方法二：
show procedure status;

查看存储过程或函数的创建代码

1
2
show create procedure proc_name;
show create function func_name;

方法三：使用Navicat客户端工具

查看在某个库下创建的存储过程，就去查看函数选项即可，支持编辑修改！

发表于 | 分类于 | 阅读次数
阅读时长 2

问题描述

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
mysql> show slave statusG;
*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: 192.168.10.100
                  Master_User: slave_user
                  Master_Port: 3306
                  Connect_Retry: 60
                  Master_Log_File: mysql-bin.000773
                  Read_Master_Log_Pos: 63325
                  Relay_Log_File: server122-relay-bin.000002
                  Relay_Log_Pos: 165661
                  Relay_Master_Log_File: mysql-bin.000771
                  Slave_IO_Running: Yes
                  Slave_SQL_Running: No
                  Replicate_Do_DB:
                  Replicate_Ignore_DB:
                  Replicate_Do_Table:
                  Replicate_Ignore_Table:
                  Replicate_Wild_Do_Table:
                  Replicate_Wild_Ignore_Table:
                   Last_Errno: 1062
                   Last_Error: Error 'Duplicate entry '1438019' for key 'PRIMARY'' on query. Default database: 'otrs'. Query: 'INSERT INTO ticket (tn, title, create_time_unix, queue_id, ticket_lock_id,  user_id, group_id, ticket_priority_id, ticket_state_id, ticket_answered,  escalation_start_time, timeout, valid_id, create_time, create_by, change_time, change_by)  VALUES ('2012061310001851', 'Your order  ORD201205A000016 was bounced back', 1339585744, 44, 1, 43,  1, 3, 4,  0, 1339585744, 0, 1,  current_timestamp, 43, current_timestamp, 43)'
                 Skip_Counter: 0
                 Exec_Master_Log_Pos: 41969067
                 Relay_Log_Space: 625695
                 Until_Condition: None
                 Until_Log_File:
                 Until_Log_Pos: 0
                 Master_SSL_Allowed: No
                 Master_SSL_CA_File:
                 Master_SSL_CA_Path:
                 Master_SSL_Cert:
                 Master_SSL_Cipher:
                 Master_SSL_Key:
                 Seconds_Behind_Master: NULL
                 Master_SSL_Verify_Server_Cert: No
                Last_IO_Errno: 0
                Last_IO_Error:
                Last_SQL_Errno: 1062
                Last_SQL_Error: Error 'Duplicate entry '1438019' for key 'PRIMARY'' on query. Default database: 'otrs'. Query: 'INSERT INTO ticket (tn, title, create_time_unix, queue_id, ticket_lock_id,  user_id, group_id, ticket_priority_id, ticket_state_id, ticket_answered,  escalation_start_time, timeout, valid_id, create_time, create_by, change_time, change_by)  VALUES ('2012061310001851', 'Your order  ORD201205A000016 was bounced back', 1339585744, 44, 1, 43,  1, 3, 4,  0, 1339585744, 0, 1,  current_timestamp, 43, current_timestamp, 43)'
1 row in set (0.00 sec)

分析原因

重复插入相同的记录，造成的主键冲突问题

解决方法

如果较少的错误可以手动解决

1
2
3
slave stop;
set global sql_slave_skip_counter=n; \ n=正整数，，看你的错误有几条，就跳过几条  
slave start;

较多的情况下增加slave_skip_errors = 1062 参数
my.cnf 中增加slave_skip_errors = 1062 参数，忽略1062错误，若忽略多个错误，中间用逗号隔开，忽略所有用all

发表于 | 分类于 | 阅读次数
阅读时长 8

MySQL 5.5 中对于二进制日志 (binlog) 有 3 种不同的格式可选：Mixed,Statement,Row，默认格式是 Statement。总结一下这三种格式日志的优缺点。

MySQL Replication 复制可以是基于一条语句 (Statement Level) ，也可以是基于一条记录 (Row Level)，可以在 MySQL 的配置参数中设定这个复制级别，不同复制级别的设置会影响到 Master 端的 bin-log 日志格式。

Row

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

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

缺点：在 row 模式下，所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容，比如有这样一条 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

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

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

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

Mixed

从官方文档中看到，之前的 MySQL 一直都只有基于 statement 的复制模式，直到 5.1.5 版本的 MySQL 才开始支持 row 复制。从 5.0 开始，MySQL 的复制已经解决了大量老版本中出现的无法正确复制的问题。但是由于存储过程的出现，给 MySQL Replication 又带来了更大的新挑战。另外，看到官方文档说，从 5.1.8 版本开始，MySQL 提供了除 Statement 和 Row 之外的第三种复制模式：Mixed，实际上就是前两种模式的结合。在 Mixed 模式下，MySQL 会根据执行的每一条具体的 SQL 语句来区分对待记录的日志形式，也就是在 statement 和 row 之间选择一种。新版本中的 statment 还是和以前一样，仅仅记录执行的语句。而新版本的 MySQL 中对 row 模式也被做了优化，并不是所有的修改都会以 row 模式来记录，比如遇到表结构变更的时候就会以 statement 模式来记录，如果 SQL 语句确实就是 update 或者 delete 等修改数据的语句，那么还是会记录所有行的变更。

其他参考信息

除以下几种情况外，在运行时可以动态改变 binlog 的格式：
. 存储流程或者触发器中间；
. 启用了 NDB；
. 当前会话使用 row 模式，并且已打开了临时表；

如果 binlog 采用了 Mixed 模式，那么在以下几种情况下会自动将 binlog 的模式由 statement 模式变为 row 模式：
. 当 DML 语句更新一个 NDB 表时；
. 当函数中包含 UUID() 时；
. 2 个及以上包含 AUTO_INCREMENT 字段的表被更新时；
. 执行 INSERT DELAYED 语句时；
. 用 UDF 时；
. 视图中必须要求运用 row 时，例如建立视图时使用了 UUID() 函数；

设定主从复制模式：

1
2
3
4
log-bin=mysql-bin
#binlog_format="STATEMENT"
#binlog_format="ROW"
binlog_format="MIXED"

也可以在运行时动态修改 binlog 的格式。例如：

1
2
3
4
5
6
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';</pre>

两种模式的对比：
Statement 优点
历史悠久，技术成熟；
产生的 binlog 文件较小；
binlog 中包含了所有数据库修改信息，可以据此来审核数据库的安全等情况；
binlog 可以用于实时的还原，而不仅仅用于复制；
主从版本可以不一样，从服务器版本可以比主服务器版本高；

Statement 缺点：
不是所有的 UPDATE 语句都能被复制，尤其是包含不确定操作的时候；
调用具有不确定因素的 UDF 时复制也可能出现问题；
运用以下函数的语句也不能被复制：

  • LOAD_FILE()
  • UUID()
  • USER()
  • FOUND_ROWS()
  • SYSDATE() (除非启动时启用了 –sysdate-is-now 选项)
    INSERT … SELECT 会产生比 RBR 更多的行级锁；
    复制须要执行全表扫描 (WHERE 语句中没有运用到索引) 的 UPDATE 时，须要比 row 请求更多的行级锁；
    对于有 AUTO_INCREMENT 字段的 InnoDB 表而言，INSERT 语句会阻塞其他 INSERT 语句；
    对于一些复杂的语句，在从服务器上的耗资源情况会更严重，而 row 模式下，只会对那个发生变化的记录产生影响；
    存储函数(不是存储流程 )在被调用的同时也会执行一次 NOW() 函数，这个可以说是坏事也可能是好事；
    确定了的 UDF 也须要在从服务器上执行；
    数据表必须几乎和主服务器保持一致才行，否则可能会导致复制出错；
    执行复杂语句如果出错的话，会消耗更多资源；

Row 优点
任何情况都可以被复制，这对复制来说是最安全可靠的；
和其他大多数数据库系统的复制技能一样；
多数情况下，从服务器上的表如果有主键的话，复制就会快了很多；
复制以下几种语句时的行锁更少：

  • INSERT … SELECT
  • 包含 AUTO_INCREMENT 字段的 INSERT
  • 没有附带条件或者并没有修改很多记录的 UPDATE 或 DELETE 语句
    执行 INSERT，UPDATE，DELETE 语句时锁更少；
    从服务器上采用多线程来执行复制成为可能；

Row 缺点
生成的 binlog 日志体积大了很多；
复杂的回滚时 binlog 中会包含大量的数据；
主服务器上执行 UPDATE 语句时，所有发生变化的记录都会写到 binlog 中，而 statement 只会写一次，这会导致频繁发生 binlog 的写并发请求；
UDF 产生的大 BLOB 值会导致复制变慢；
不能从 binlog 中看到都复制了写什么语句(加密过的)；
当在非事务表上执行一段堆积的 SQL 语句时，最好采用 statement 模式，否则很容易导致主从服务器的数据不一致情况发生；
另外，针对系统库 MySQL 里面的表发生变化时的处理准则如下：
如果是采用 INSERT，UPDATE，DELETE 直接操作表的情况，则日志格式根据 binlog_format 的设定而记录；
如果是采用 GRANT，REVOKE，SET PASSWORD 等管理语句来做的话，那么无论如何都要使用 statement 模式记录；
使用 statement 模式后，能处理很多原先出现的主键重复问题；

发表于 | 分类于 | 阅读次数
阅读时长 1

问题

在编译libmcrypt软件包时出现问题

1
2
3
4
/libltdl.a(ltdl.o): relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC
/usr/local/lib/libltdl.a(ltdl.o): could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [libphp4.la] Error 1

解决方法

1
2
yum install libtool-ltdl-devel
//PHP_LDFLAGS=-L/usr/lib64 ./build php n

发表于 | 分类于 | 阅读次数
阅读时长 4

问题

启动 centos5.6出现下面提示 Memory for crash kernel (0x0 to 0x0 notwithin permissible range)

解决方法

kexec是一个快速启动机制，允许通过已经运行的内核的上下文启动一个Linux内核，不需要经过BIOS。BIOS可能会消耗很多时间，特别是带有众多数量的外设的大型服务器。这种办法可以为经常启动机器的开发者节省很多时间。
kdump是一个新的，而且非常可信赖的内核崩溃转储机制。崩溃转储数据可以从一个新启动的内核的上下文中获取，而不是从已经崩溃的内核的上下文。当系统崩溃时，kdump使用kexec启动到第二个内核。第二个内核通常叫做捕获内核（capture kernel），以很小内存启动，并且捕获转储镜像。
第一个内核保留了内存的一部分，第二个内核可以用来启动。注意，在启动时，kdump保留了一定数量的重要的内存，这改变了紅帽企业Linux 5最小内存需求。为了计算系统需要的真正最小内存，可以参看 [url]http://www.redhat.com/rhel/details/limits/[/url] 上列出的最小内存需求，加上kdump使用的内存数量，以决定真正的最小内存的需求。

因为第一内核的内存内容已经被保留，所以kexec可以不经过BIOS，启动捕获内核。这是内核崩溃转储的根本。

怎样配置kdump

  1. 确认kexec-tools已经安装：

    1
    #rpm -q kexec-tools

  2. 配置/etc/kdump.conf文件，指定vmcore将被转储的路径。可以通过scp拷贝到另一个服务器，也可以是裸设备，或者本地的文件系统。

  3. 修改一些启动参数，为捕获很保留一块内存。对于i386和x86_64架构，编辑/etc/grub.conf，在内核行的末尾添加 crashkernel=128@16M。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    下面是一个带有kdump选项的/etc/grub.conf文件：
    # grub.conf generated by anaconda
    #
    # Note that you do not have to rerun grub after making changes to this file
    # NOTICE:  You do not have a /boot partition.  This means that
    #          all kernel and initrd paths are relative to /, eg.
    #          root (hd0,0)
    #          kernel /boot/vmlinuz-version ro root=/dev/hda1
    #          initrd /boot/initrd-version.img
    #boot=/dev/hda
    default=0
    timeout=5
    splashimage=(hd0,0)/boot/grub/splash.xpm.gz
    hiddenmenu
    title Red Hat Enterprise Linux Client (2.6.17-1.2519.4.21.el5)
            root (hd0,0)
            kernel /boot/vmlinuz-2.6.17-1.2519.4.21.el5 ro root=LABEL=/ rhgb quiet crashkernel=128M@16M
            initrd /boot/initrd-2.6.17-1.2519.4.21.el5.img

4.修改之后，重启系统。128M内存（从16M开始）不被正常的系统使用，为捕获内核保留。注意，free -m的输出会显示内存比不加参数时少了128M，这就是我们所期望的。

注意：可以使用小于128M，但是只使用64M做测试被证实是不可靠的。

5.现在，保留内存已经设置了，打开kdump初始脚本，启动服务：

1
2
#  chkconfig kdump on
#  service kdump start

6.可以通过kexec加载内核镜像，让系统准备捕获一个崩溃时产生的vmcore。可以通过sysrq强制系统崩溃：

1
# echo "c" &gt; /proc/sysrq-trigger

这造成kernel panic，紧跟着系统重启kdump内核。当启动进程进入到启动kdump服务器时，vmcore将会被拷贝到你在/etc/kdump.conf文件中指定的位置。

注意：

终端frame-buffer和X将运行不正常。在运行一些类似于在内核配置上添加了”vga=791”或者运行X的系统，在通过kexec启动内核时，终端显示将不清楚。记住，kdump内核仍旧能够创建转储。当系统重启，显示将会恢复到正常状态。

发表于 | 分类于 | 阅读次数
阅读时长 1 
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
select * from v$version;                查看服务器版本
select * from all_users;                ##查看所有用户
select name from v$database;            ##查看当前数据库
database test;                          ##进入test数据库
select * from v$instance;               ##查看所有的数据库实例
shutdown immediate                      ##关闭数据库
alter user sys identified by new_password;        ##更改用户密码
select username,password from dba_users;          ##查看当实例中的用户和密码
show parameter control_files;                     ## 查看控制文件;
select member from v$logfile;                     ##查看日志文件
show parameter ;                                  ## 查看数据库参数
select * from user_role_privs;                    ##查看当前用户的角色
select username,default_tablespace from user_users; ##查看当前用户的缺省表空间
alter user system identified by [password]        ##修改用户的密码
ALTER USER "SCOTT" ACCOUNT UNLOCK                 ##解锁SCOTT用户
show parameter processes;                         ##查看最大会话数
select username,sid,serial# from v$session;  查看当前会话连接
select * from all_tables;                         ##查看当前库的所有数据表
查看表结构：desc all_tables;
创建用户并赋予权限
###----------------------------创建用户并赋予权限------------------------------------####-
create user mpss
    identified by "mpss12"
    default tablespace TS_MPSS_DATA
    temporary tablespace TEMP;
给用户赋予权限
grant connect to mpss;
grant resource,create session to mpss;  开发角色
grant create procedure to dbuser；＃这些权限足够用于开发及生产环境
给用户授权
grant dba to spms;--授予DBA权限
grant unlimited tablespace to lxg;--授予不限制的表空间
grant select any table to lxg;--授予查询任何表
grant select any dictionary to lxg;--授予 查询任何字典

发表于 | 分类于 | 阅读次数
阅读时长 2

方法一:
　　通过information_schema.processlist表中的连接信息生成需要处理掉的MySQL连接的语句临时文件，然后执行临时文件中生成的指令。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
mysql> select concat('KILL ',id,';') from information_schema.processlist where user='root';
+------------------------+
| concat('KILL ',id,';') |
+------------------------+
| KILL 3101;             |
| KILL 2946;             |
+------------------------+
2 rows in set (0.00 sec)
mysql> select concat('KILL ',id,';') from information_schema.processlist where user='root' into outfile '/tmp/a.txt';
Query OK, 2 rows affected (0.00 sec)
mysql>source /tmp/a.txt;
Query OK, 0 rows affected (0.00 sec)

方法二:
杀掉当前所有的MySQL连接

1
2
3
mysqladmin -uroot -p processlist|awk -F "|" '{print $2}'|xargs -n 1 mysqladmin -uroot -p kill
杀掉指定用户运行的连接，这里为Mike
mysqladmin -uroot -p processlist|awk -F "|" '{if($3 == "Mike")print $2}'|xargs -n 1 mysqladmin -uroot -p kill

方法三:
通过SHEL脚本实现

1
2
3
4
5
#杀掉锁定的MySQL连接
for id in `mysqladmin processlist|grep -i locked|awk '{print $1}'`
do
   mysqladmin kill ${id}
done

方法四:
通过Maatkit工具集中提供的mk-kill命令进行

1
2
3
4
5
6
#杀掉超过60秒的sql
mk-kill -busy-time 60 -kill
#如果你想先不杀，先看看有哪些sql运行超过60秒
mk-kill -busy-time 60 -print
#如果你想杀掉，同时输出杀掉了哪些进程
mk-kill -busy-time 60 -print –kill

mk-kill更多用法可参考：

http://www.maatkit.org/doc/mk-kill.html
http://www.sbear.cn/archives/426

Maatkit工具集的其它用法可参考：

http://code.google.com/p/maatkit/wiki/TableOfContents?tm=6

参考

　http://www.orczhou.com/index.php/2010/10/kill-mysql-connectio-in-batch/
　http://www.mysqlperformanceblog.com/2009/05/21/mass-killing-of-mysql-connections/

发表于 | 分类于 | 阅读次数
阅读时长 1

问题描述

···
[root@monitor pdo_mysql]# phpize
Configuring for:
PHP Api Version: 20090626
Zend Module Api No: 20090626
Zend Extension Api No: 220090626
config.m4:138: warning: AC_CACHE_VAL(pdo_inc_path, …): suspicious cache-id, must contain cv to be cached
../../lib/autoconf/general.m4:1974: AC_CACHE_VAL is expanded from…
../../lib/autoconf/general.m4:1994: AC_CACHE_CHECK is expanded from…
aclocal.m4:2748: PHP_CHECK_PDO_INCLUDES is expanded from…
config.m4:138: the top level
config.m4:138: warning: AC_CACHE_VAL(pdo_inc_path, …): suspicious cache-id, must contain cv to be cached
../../lib/autoconf/general.m4:1974: AC_CACHE_VAL is expanded from…
../../lib/autoconf/general.m4:1994: AC_CACHE_CHECK is expanded from…
aclocal.m4:2748: PHP_CHECK_PDO_INCLUDES is expanded from…
config.m4:138: the top level

1
2
#### 解决方法

autoconf版本太高造成的,我的办法是安装autoconf 2.13
redhat类系统运行如下命令
yum install autoconf213.noarch
export PHP_AUTOCONF=/usr/bin/autoconf-2.13
export PHP_AUTOHEADER=/usr/bin/autoheader-2.13

64位环境下
configure: error: libjpeg.(a|so) not found.
或者 configure: error: *.(a|so) not found.
这些库已经安装了但还报错
在configure 时加参数 –with-libdir=lib64
```

发表于 | 分类于 | 阅读次数
阅读时长 1

问题描述

LAMP架构服务，早上网站打不开，ssh登录连接不上服务器，能ping通，域名能解析

日志截图：

问题分析

此问题出在TCP连接造成，由于安全考虑系统启用了iptables防火墙，有conntrack模块，此模块用于跟踪并且记录连接状态，连接跟踪是防火墙模块的状态检测的基础，一个跟踪连接表会占用350字节的内核存储空间，系统运行时间长时就会把默认的空间填满（IP_conntrack），需要定期清理。

解决方法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
1.加大 ip_conntrack_max 值
vi /etc/sysctl.conf
net.ipv4.ip_conntrack_max = 655360
2.降低 ip_conntrack timeout 时间
vi /etc/sysctl.conf
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 180
#sysctl -p 生效
查看目前 ip_conntrack buffer 使用状况
grep conn /proc/slabinfo
查出目前 ip_conntrack 记录最多的前五名 IP
cat /proc/net/ip_conntrack | cut -d ' ' -f 10 | cut -d '=' -f 2 | sort | uniq -c | sort -nr | head -n 5