请谅解,我不对前家公司的任何事情发表任何评论

离开前家公司,快半年了。
经常有人在qq或者mail或者电话问我,说是想去我前家公司,问我前家公司怎么样。说实话,我很理解,去一家公司之前,先了解下这个公司的心态,如果我处在他们的位置,我也会找个人问的。
但是,也请谅解,我不会对前家公司的任何事情作出任何的评论。任何事情,冷暖自知,如果我说好,你去了,感觉不好,会回过头来骂我;如果我说不好,你没去,结果后悔,这个责任也是我不能承受的。
而且,站在我的角度,我也不知道应该说好,还是说不好。说好,人家会问,那你为啥离职?说不好,人家会说,那你怎么还待了靠近三年。
还是那句话,冷暖自知!!!

BCM培训小结

业务连续性管理(Business Continuity Management,简称BCM),是一项综合管理流程,它使企业认识到潜在的危机和相关影响,制订响应、业务和连续性的恢复计划,其总体目标是为了提高企业的风险防范能力,以有效地响应非计划的业务破坏并降低不良影响。
BCM规划与实施包括企业信息系统的基础数据、应用系统与业务的灾难备份与恢复计划。

BCM一共有六个大的步骤,分别是:

BCM范围识别,其主要目的是识别关键的业务和资源(这个部分非常关键,如果这个部分出现偏差,则会导致整个BCM偏差);

BCM风险分析,其主要目的是分析业务中断时的影响,这里有两个非常关键的概念,MTPD,最大可容忍的业务中断时间;RTO,恢复目标时间;这个部分也称为BIA,如果这个部分分析错误,则会导致整个BCM失败(这个部分很关键,BIA部分也是整个BCM部分最难的);

BCM策略,主要是完成总体业务持续管理策略,活动选择性策略以及资源层的整合;在这个部分要考虑PPTISSC(这个部分是BCM的金团队,也就是老板们决定的事情);

BCM反应和计划,也就是BCP过程,基于BCM策略,业务影响分析,风险评估和BCM策略,开发和执行适当的BCM计划和安排(这个部分需要无数的文档来完成,也是整个BCM过程中最累的部分);

后面两个步骤是BCM培训和维护,就比较简单点了。

BCM的一切都是基于假想的,BCM关注的是关键业务中断的时候,所采取的措施。

对于一个互联网企业,其关注的应该是能引起关键业务中断的事件的管理。例如,IDC机房整体瘫痪,员工群发性自杀,工作所在地发生严重的自然灾害等情况。平时的容灾呀,备份呀考虑的层面应该都小于BCM。

BCM和风险管理有着本质的区别,其区别主要在于:
(下图摘自DNV在BCM培训中的部分,版权属于DNV)

需要记住的是,BCM关注于业务的恢复,而不是业务为什么发生中断,一般来说,BCM的启动都是基于事件已经发生,而不是事件可能发生。

支付宝?这么烂的用户体验?

IE8,登录支付宝,准备进行信用卡还款,连续三次都是下面这个界面

image 

看看这到底是个啥垃圾???????????????????????

启动转岗流程

入职靠近四个月的时候,正式启动了我的转岗流程。

从预研部的高级DBA转岗到研发部-运维的职位,从P线转岗到M线。不知道以后会累成啥样了。

世界杯开幕了

世界杯开幕了,相信很多人会去看世界杯。
可是偶,对足球一窍不通,只能看别人狂欢了。
或许这一个月,是很多人的盛宴,我就可以好好工作了,嘿嘿,希望晚上不要被看球的人吵醒。

预祝alan,lori,doris的ocm考试通过

今天得到lori的消息,他也报名参加ocm考试了。
以前我们在zmcc团队一共四个人,我,alan,lori,doris。去年11月,我通过了ocm考试,后来由于种种原因,今年的3月选择了离开那个团队。
如果他们三个一起考过,那应该是这个team原来的四个人全部都是ocm了,也是可以让我自豪的事情了。
在此,预祝他们,一次全部通过。

mysql 1045(28000)错误

今天不知道怎么了,在windowns 7上安装mysql,就是不成功,后来没有办法去,在http://dev.mysql.com/downloads/mysql/下了个免安装的版本,解压后,用是能用了。

给应用测试的人建立了一个测试的数据库和用户,奇怪的是,在本地登录没事,远程登录,无论如何都报10045(28000)错误。

C:\Windows\system32>mysql -uuism -h 172.16.9.43
ERROR 1045 (28000): Access denied for user ‘uism’@’172.16.5.20′ (using password:
YES)

检查系统的user表,发现结果如下:
mysql> select user ,host ,password from user;
+——+———–+——————+
| user | host | password |
+——+———–+——————+
| root | localhost | |
| root | 127.0.0.1 | |
| | localhost | |
| uism | localhost | 16cfa8943c7fb191 |
| uism | % | |
| uims | % | |
+——+———–+——————+
6 rows in set (0.00 sec)

用户在本地登录是好的,远程无论如何都不行,不管给不给密码。查询网络发现,需要将user表中那个用户名为空的用户干掉;

mysql> delete from user where user is null;
Query OK, 0 rows affected (0.00 sec)

mysql> delete from user where user =”;
Query OK, 1 row affected (0.00 sec)
这里看看,原来这个用户名还不是null,只是一个空字符串,晕倒。
然后,重新更新下权限,
mysql> flush privileges;
Query OK, 0 rows affected (0.00 sec)

再在客户端做链接:
C:\Windows\system32>mysql -uuism -h172.16.9.43
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 103
Server version: 5.1.47-community MySQL Community Server (GPL)

Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the current input statement.

mysql>

Mysql怎么会有这么搞笑的问题,哈哈,而且那个用户的host为%的那个,密码为空,现在变成了远程不需要密码,本地需要密码,囧!

加入我们,蛋糕西瓜伺候

上周五开始,每天下午靠近四点有蛋糕吃,而且上周五开始有西瓜,不过人太多,上周差点没抢到。

今天下午,居然是公司的pp行政来一个一个的发,每人一份西瓜和蛋糕。

下面是这两吃的的图片,加入我们吧,天天上班吃蛋糕和西瓜:)

mysql问题一例

今天开始处理我们的后台数据库中的一个mysql的问题,问题症状是,每天有个不固定的时间,整个系统的sql执行会非常慢,如果你不理他,过会就自己好了。

简单分析了下,那个系统就两个表,被设计成了mysql cluster模式。

在slow log中有如下内容:

………

Count: 3568  Time=0.00s (0s)  Lock=0.00s (0s)  Rows=0.0 (0), session[session]@localhost
# Query_time: N.N  Lock_time: N.N Rows_sent: N  Rows_examined: N
SET timestamp=N;
select * from session where sky_id=N
Count: 284  Time=0.00s (0s)  Lock=0.00s (0s)  Rows=0.0 (0), session[session]@localhost
# Query_time: N.N  Lock_time: N.N Rows_sent: N  Rows_examined: N
SET timestamp=N;
delete from session where sky_id=N
Count: 690  Time=0.00s (0s)  Lock=0.00s (0s)  Rows=0.0 (0), session[session]@localhost
# Query_time: N.N  Lock_time: N.N Rows_sent: N  Rows_examined: N
SET timestamp=N;
insert into session(sky_id, user_name, nick_name, nick_name1, gender, age, portrait_id, token, province, city, pos_code, pos_desc, acc_esbaddr, acc_session_index, acc_type, ip, alive_check, rand_tag, last_oltime, logintime) values(N, ‘S’, ‘S’, ‘S’, N, N, N, N, ‘S’, ‘S’, N, ‘S’, N, N, N, ‘S’, N, N, N, N)
Count: 1572  Time=0.00s (0s)  Lock=0.00s (0s)  Rows=0.0 (0), session[session]@localhost
# Query_time: N.N  Lock_time: N.N Rows_sent: N  Rows_examined: N
SET timestamp=N;
select * from session where sky_id in (N,N)

Count: 3568  Time=0.00s (0s)  Lock=0.00s (0s)  Rows=0.0 (0), session[session]@localhost  # Query_time: N.N  Lock_time: N.N Rows_sent: N  Rows_examined: N  SET timestamp=N;  select * from session where sky_id=N
Count: 284  Time=0.00s (0s)  Lock=0.00s (0s)  Rows=0.0 (0), session[session]@localhost  # Query_time: N.N  Lock_time: N.N Rows_sent: N  Rows_examined: N  SET timestamp=N;  delete from session where sky_id=N
Count: 690  Time=0.00s (0s)  Lock=0.00s (0s)  Rows=0.0 (0), session[session]@localhost  # Query_time: N.N  Lock_time: N.N Rows_sent: N  Rows_examined: N  SET timestamp=N;  insert into session(sky_id, user_name, nick_name, nick_name1, gender, age, portrait_id, token, province, city, pos_code, pos_desc, acc_esbaddr, acc_session_index, acc_type, ip, alive_check, rand_tag, last_oltime, logintime) values(N, ‘S’, ‘S’, ‘S’, N, N, N, N, ‘S’, ‘S’, N, ‘S’, N, N, N, ‘S’, N, N, N, N)
Count: 1572  Time=0.00s (0s)  Lock=0.00s (0s)  Rows=0.0 (0), session[session]@localhost  # Query_time: N.N  Lock_time: N.N Rows_sent: N  Rows_examined: N  SET timestamp=N;  select * from session where sky_id in (N,N)

………………..

这段代码看,执行慢最多的sql居然是在session表上的,看看session表的结构

mysql> desc session;

+——————-+———————+——+—–+———+——-+

| Field             | Type                | Null | Key | Default | Extra |

+——————-+———————+——+—–+———+——-+

| sky_id            | int(10) unsigned    | NO   | PRI | NULL    |       |

| user_name         | char(32)            | NO   |     | NULL    |       |

| nick_name         | char(32)            | YES  |     | NULL    |       |

| nick_name1        | char(64)            | YES  |     | NULL    |       |

| gender            | tinyint(1)          | YES  |     | NULL    |       |

| age               | int(10) unsigned    | YES  |     | NULL    |       |

| portrait_id       | int(10) unsigned    | YES  |     | NULL    |       |

| token             | int(10) unsigned    | YES  |     | NULL    |       |

| province          | char(32)            | YES  |     | NULL    |       |

| city              | char(32)            | YES  |     | NULL    |       |

| pos_code          | int(10) unsigned    | YES  |     | NULL    |       |

| pos_desc          | varchar(64)         | YES  |     | NULL    |       |

| acc_esbaddr       | int(10) unsigned    | YES  |     | NULL    |       |

| acc_session_index | int(10) unsigned    | YES  |     | NULL    |       |

| acc_type          | tinyint(3) unsigned | YES  |     | NULL    |       |

| ip                | char(15)            | YES  |     | NULL    |       |

| alive_check       | int(10) unsigned    | YES  |     | NULL    |       |

| longitude         | int(11)             | YES  | MUL | NULL    |       |

| latitude          | int(11)             | YES  | MUL | NULL    |       |

| loc_desc          | varchar(64)         | YES  |     | NULL    |       |

| rand_tag          | int(11)             | YES  | MUL | NULL    |       |

| mid               | varchar(256)        | YES  |     | NULL    |       |

| last_oltime       | int(11)             | YES  |     | 0       |       |

| logintime         | int(11)             | YES  |     | 0       |       |

+——————-+———————+——+—–+———+——-+

24 rows in set (0.05 sec)

可以看出,sky_id上是主键

再看看这个执行最慢的几个sql的执行计划:

mysql>  explain select * from session where sky_id=112414853 \G;

*************************** 1. row ***************************

id: 1

select_type: SIMPLE

table: NULL

type: NULL

possible_keys: NULL

key: NULL

key_len: NULL

ref: NULL

rows: NULL

Extra: Impossible WHERE noticed after reading const tables

1 row in set (0.00 sec)

ERROR:

No query specified

mysql>

mysql>

mysql> explain select * from session where sky_id in (112414853,-1,-1) \G;

*************************** 1. row ***************************

id: 1

select_type: SIMPLE

table: session

type: range

possible_keys: PRIMARY

key: PRIMARY

key_len: 4

ref: NULL

rows: 2

Extra: Using where with pushed condition

1 row in set (0.00 sec)

ERROR:

No query specified

居然,既然,在主键上使用了=比较的sql,执行计划不正常。
这个问题,到现在我还没分析出来是为啥,不过,千万别告诉我,第一次处理mysql的问题就是bug,虽然我个人觉得很像是某个bug
最后,看看我的数据库的版本吧
mysql> select version();
+——————————-+
| version()                     |
+——————————-+
| 5.1.27-ndb-6.3.17-cluster-gpl |
+——————————-+
1 row in set (0.01 sec)
嗯,还有操作系统的版本:
Linux 2.6.18-92.el5PAE #1 SMP 2008 i686 i686 i386 GNU/Linux
欢迎mysql高手,就这个问题给予建议。
—————————HLL的分隔线————————————————–
在昨天晚上的跟踪中,应用发现,出现过一次堵塞的情况,持续了大概一分多钟,幸运的是,抓取到了部分信息,不幸的是,只抓取到堵塞后期的信息。抓取到的信息如下:
» Read more…

以下职位,诚招!

资深开发DBA

工作地点:杭州

技能要求:

1.精通SQL代码编写

2.熟悉SQL优化

3.精通数据库建模

4.良好的沟通技能、团队合作能力

5.具有良好的数据建模能力

6.掌握数据库开发与设计工具的使用

7.三年以上开发DBA工作经验

8.至少熟悉掌握ORACLE/POSTGRESQL/MYSQL中的一种

9.有开发经验者优先

工作职责:

1.负责 DB 开发、以及开发/测试库的日常维护;

2.负责 DB Schema 设计以及评审;

3.完善和宣贯 DB 开发规范和相关流程,提高应用开发人员 DB 开发技能。

4.评估,跟踪,支持开发项目

5.数据库变更管理

6.数据库开发相关性能优化

7.开发、测试环境管理与维护

这个岗位的人,我会亲自带,目前隶属在公司最为核心的研发部门。发展机会非常不错,目前定位是资深开发dba,目标定位是开发dba主管,有兴趣的人,给我简历。

guoyue@gmail.com