樱桃沟夹事

Timo's life

发表于 更新于 分类于 本文字数： 363 阅读时长 ≈ 1 分钟

以前一直用touch用来产生新文件的，也没有过多注意，因为只是一个这样简单的功能，今天因为要手动修改文件的访问时间，问了下google居然touch就可以实现这个功能。
命令格式如下，这个我是为了修改它的访问时间。 

1
2
3
4
5
6
7
8
9
touch -a --date='2010-05-16 09:09' abc 
```  
这个我是生成一个叫abc，并且访问时间是定义在2010年5月16日9点9分。  
通过man touch就能看到touch的很多使用方法  
-m 是修改mtime时间， -a 就是修改atime  
而要查看文件修改时间如下：  
```bash
# 查看文件的变动时间 
ll --time=atime abc ll --time=ctime abc ll --time=mtime abc

发表于 更新于 分类于 本文字数： 1.4k 阅读时长 ≈ 1 分钟

对于互联网公司squid是必不可缺的。 而要确认所有squid节点是否压缩正常是比较麻烦的事情。

但是其实用wget就可以解决这个问题，我们可以把这个写到nagios插件中使用就可以了。

这里我们使用www.zongheng.com的一个squid节点58.215.101.182 

 wget -S --spider --header="Accept-Encoding:gzip,deflate" --header="Host:www.zongheng.com" http://58.215.101.182

以下为参数解释
-S: 打印出响应头信息。下面是打印出的信息。 

 开启 Spider 模式。检查是否存在远程文件。 --2010-07-18 10:33:10-- http://58.215.101.182/ 正在连接 58.215.101.182:80... 已连接。 已发出 HTTP 请求，正在等待回应... HTTP/1.0 200 OK Server: ZHWS-0.6 Date: Sun, 18 Jul 2010 02:33:11 GMT Content-Type: text/html; charset=UTF-8 Vary: Accept-Encoding Cache-Control: no-cache Expires: Thu, 01 Dec 1994 16:00:00 GMT Set-Cookie: JSESSIONID=abchaeKZaaLJ25EcuzJNs; path=/ Content-Encoding: gzip X-Cache: MISS from zw2squid.zongheng.com X-Cache-Lookup: MISS from zw2squid.zongheng.com:80 Via: 1.0 zw2squid.zongheng.com:80 (squid/2.6.STABLE21) Connection: keep-alive
阅读全文 »

发表于 更新于 分类于 本文字数： 713 阅读时长 ≈ 1 分钟

从世博会归来也快2周了，但是因为世界杯的缘故，一直没有放上照片。现在一并贴上，废话不多说了，因为排了4个小时的队就仔细看了德国馆，其它馆就外面看了看。 这个是在等待入场呢，还好加了顶棚和洒水装置，不然还没进场估计有些人就要吃不消了
 

排队无聊互相对拍呢

终于过安检了，老妈等着大家呢

中国馆就在眼前
 

伯母说香港馆的小兔子很好玩。
 

坐车路过联合馆
 

阅读全文 »

发表于 更新于 分类于 本文字数： 665 阅读时长 ≈ 1 分钟

搜索了很多，以为是自己的ubuntu有问题，还是10.04版本有BUG导致无法同步，但是查看日志也是正常的，ubuntu one也是正常状态。
今天找了很多来到了官方网站终于找到原因了。
https://wiki.ubuntu.com/UbuntuOne/Status#Contacts Monday, May 17, 2010: 585530 Sync between your desktops and the cloud continues to be disabled as we rollout database server improvements to stabilize.
Monday, June 7, 2010: We are in the process of migrating customers to the upgraded database server environment. We will re-enable desktop sync for this service when we have migrated more customers. Sorry for the delay. 算了，等它自己突然好吧。 —————————————————————————— Best regards Timo Seven ttp://zauc.wordpress.com twitter: http://twitter.com/twitter UNIX System Admin

发表于 更新于 分类于 本文字数： 4.7k 阅读时长 ≈ 4 分钟

1989年6月的民主运动

谈到六四，我最常遇到的一个问题，就是：假如八九民运成功，会是怎样？尽管历史已经发生，不能假设；但是这样的问题从来没有中断过，所以我还是想谈谈自己的看法。

要回答这个问题，首先就要定义什么是八九民运的“成功”。外界对八九民运最大的误解之一，就是“如果你们上台，就会比共产党更好吗”这类的质疑。这个冠冕堂皇的质疑其实完全是一个假问题，因为八九年的学生从来没有提出取代共产党，我们自己上台的主张，而且不管八九民运最后如何发展，也根本不可能出现所谓学生领袖成为国家领导人这样的事情。有些人拿这些莫须有的推测作为现实中的质疑理由，然后站在道德的制高点上评判历史，这是极大的荒谬。

成功，指的是达到目的。八九民运的政治主张最早是在1989年4月18日由包括我在内的学生代表在人民大会堂会见中共中央和国务院信访局领导的时候提出的所谓“请愿七条”，包括正确评价胡耀邦同志的是非功过，彻底否定“清除精神污染”“反对资产阶级自由化运动”，为在运动中蒙受不白之冤的公民平反；公布国家领导人的年薪收入及一切形式的收入；允许民主办报刊，新闻自由，限期解除报禁；增加教育经费等等。在运动发展过程中，陆续有更多的政治主张出现，但是大致的范围也与上述“七条”有类似之处。但是我认为，如果要确认什么是八九民运的成功，还是应当以5月13日学生绝食提出的两个条件作为权衡标准，因为绝食导致学生运动转化为全民民主运动，之后全国的声援力量都集中在要求政府接受学生的绝食要求上，因此，假如八九民运成功，那么就意味着，政府最终接受了绝食学生的两个要求。

这两个要求是：第一，要求政府迅速与北京高校对话代表团进行实质性的，具体的真正平等的对话；第二，要求政府为这次学生运动正名，并给予公正评价，肯定这是一场爱国民主的学生运动。

因此，讨论“假如八九民运成功”这个问题，就是要讨论，如果政府开始与学生对话，并肯定了学生运动的爱国性质，对于中国未来的发展会有什么样的影响。我认为，最大的影响会是以下三个：

阅读全文 »

发表于 更新于 分类于 本文字数： 4.8k 阅读时长 ≈ 4 分钟

——讲述给里德听的我的家谱

伦 纳德·里德，秋风译

附：米尔顿·弗里德曼为本文写的导语

我是一支铅笔——最普通的木杆铅笔，只要是能读会写的男女老少都最再熟悉不过的铅笔*。

写字是我的职责，也是我的业余爱好；那是 我的全部工作所在。

你肯定有点奇怪，我干嘛要搞一个什么家谱。好吧，我来解释一下，嗯，首先，因为我的故事很有 趣。其次，我是一件神秘的东西——要比树 木、比日落、甚至比闪电要神秘多了。不过，很不幸，那些用我的人把我看得平淡无奇，就好象我完全是自己钻出来的，一点背景都不需要。这种目空一切的心态把 我归入大路货的档次。这实在是一个令人伤痛的错误，而如果人们一直犯这种错误，难免会出乱子。因为，博学的G. K. Chesterton曾经说过：“我们会因为缺乏好奇而毁灭，而不会因为期望奇迹而毁灭。”

阅读全文 »

发表于 更新于 分类于 本文字数： 1.8k 阅读时长 ≈ 2 分钟

《时间管理–给系统管理员的》这本书之前出英文版的时候就看了点开头，现在出了中文版的PDF终于算是全部看完了。
看后的感受特整理如下。
使用笔记（将其它需要处理的事情记录在笔记上），将脑力集中在当前事务中，而记录需要处理的事情就会让大脑只专注于当前，而不会去想还有其它的事情需要处理。那样只会让自己分心。
将脑力集中在重要的事情上，这个对于主次不分的我还是很有用处的。
形成自然习惯，按照一个资料的说法，如果你连续21天做同样的事情，那你就会对那个事情形成习惯。
迟早都要做的事情，晚做不如早做。
每天早上花5分钟计划一天。
减少中断，努力在被中断前完成当前的事情。
把需要记住的事情在大脑中清除，而把这些事情记录在笔记上或者电脑上。
关闭IM和EMAIL，我自己曾经试过这样一天，果然效率提高很多。
每天上班的第一个小时用在重要的工作上。这个可能每个人不一样，我自己是下午3点到5点是效率最高的时间。
当有人来干扰你的时候，你可以进行委派给其他同事，记录下事情，或者立即执行。
永远测试你的工作。这个我是深有体会的，特别是这次在做ETL迁移的时候，很多都是很细节的东西，涉及到的步骤又特别多，所以必须对于每一步都要进行测试，不然以后排错就麻烦了，也会造成统计数据不准，不能出很多同事的KPI了。
放手开始做，事实不会那么难的。其实对于SA，DBA很少有没法解决的技术问题，我们又不是研究型工作，需要攻克什么课题。
与其它相关部门进行沟通。这个是很有必要的，作为一个DBA需要跟技术沟通，有时候产品设计不合理导致数据库压力非常大，这个时候还要跟产品沟通。有时候要跟运营直接沟通。
创建自己的例行公事：重复没有安排到的事情，维护工作，人际关系与职业风格，耽误很久时间时就开始行动吧。
对于低优先级的事情偶尔可以进行忽略。
开发新技能，并能持续更新。这个算是技术人员的悲哀了。
时间管理里面很重要的一部分就是目标管理，有分今日目标管理，短期目标管理和长期目标管理。
写下你的所有目标，并定期进行回顾。要是你不写下，你也许会忘记。
制定的目标应该可以测量：目标需要有具体的结果或者数量值来作为测量标准。
目标应该设有截止日期。
目标设置可以分为1个月，1年目标以及5年目标。
对于来自上司的请求你还是能马上完成还是尽力的马上完成，毕竟他是最终考核你的人。
管理你的上司：让他协助你发展你的职业生涯，你要跟你的上司沟通你最终的目标等等。
知道何时使用往上委派，了解其目标并做出贡献。
根据客户期望来排定事务的优先级。
面对压力时我还是建议你没小时都出去走走，这样会减缓很多眼里。
余家，冥想，按摩都是很好的减压方式。
如何管理email
1 过滤器
2 删除未读邮件（如果一个事情很紧急你肯定会立刻读，对于那些长久没有读的邮件就应该立刻删除）
3 使用IMAP协议，这样在邮件服务器上也会使用过滤器。
4 对于每一封邮件我们必须一下子看完，然后做决定。
常见的浪费时间的事情： 工作表内有垃圾内容，订阅的邮件列表太多等等

书写文档

我见过很多SA和DBA都不喜欢写文档，感觉这个太费时间。

书写文档分为2种，一个是面向客户的储藏库：把你客户要用到的流程写成文档。这样省去了这些客户以后再来找你，中断你自己的工作。

内部IT储藏库，你的内部所需要协助做好的工作信息。

其实无论是对于系统管理员而言，还是对于数据库管理员，或是其它IT支持类的工作都免不了被打扰，所以进行时间管理还是很有必要的，当然文中的作者是从较高的层次来说的，毕竟作者的级别高，跟我们这种普通员工关于时间管理的内容还是很不一样的。
作者每天处理的事情都是很久之前可以确定的，确定一个大目标来进行1周的处理。
而作为我们普通员工时间管理的意义就是看看自己每天工作都花在了哪些地方，这也是刚开始做时间管理必须要经历的一个过程。比如我现在每天都用evolution来写下每个小时每天都在做哪些工作，这样每周报告和总结的时候有很多依据来进行。而等过了这个过程时候就要进行更多的规划性的内容。而不是一直陷入在日常事务性工作。
就好比我从上个月开始就想要完成的MYSQL DRBD的测试工作，可至今没有完成，从本周的时间记录来看，大部分时间都花在了对于产品和运营的支持上了，而对于DBA本职工作，关于数据平台ETL的迁移花的时间只有30%左右。 可见还是被经常打断，但是很多时候会自我中断，有时候会参加同事的讨论，有时候会上上论坛看看新闻等等。

阅读全文 »

发表于 更新于 分类于 本文字数： 495 阅读时长 ≈ 1 分钟

mysql的单点一直是一个让人很烦恼的事情，特别是master的单点。
现在外面的解决方案主要如下： 双master方案，heartbert(HA)+rhcs(分布式文件系统)，heartbert(HA)+DRBD.
双master存在的问题是master有2个IP，这样意为着前端需要指向2个的masterIP，同时bin-log也是双向同步的，会不会比单向同步的量更多呢？
第二种方案是挺不错的，但是必须要分布式文件系统，要是实在不行就可以用NFS来代替，但是这样存在的问题就是数据文件是单点，所以必须使用分布式文件系统。
第三种是关键是DRBD，这个是在网络层做RAID1，在A机器上收到数据后DRBD会写到本地硬盘上，同时通过网络传输到另外一台机器上。这样保证了2台机器的一致。特别是DRBD传输的时候有多种协议可以选择，但是一般看到网上大家都是使用协议C（C表示收到远程主机的写入确认后,视为写入完成）
DRBD的架构如下：
今天在high scalability有个文档专门比较各种mysql HA的方案。基本上大家可以根据这个比较来做自己合适的的MySQL HA了
2010-05-09

发表于 更新于 分类于 本文字数： 8.1k 阅读时长 ≈ 7 分钟

第三章 架构优化和索引

第三章的主要是说合理使用不同的数据类型和索引。主要需要注意的内容有如下：

  1. 通用原则
    1.1. 数据类型更小通常更好。
    1.2. 数据类型越简单越好
    1.3. 尽量避免使用NULL,要是有必要用NULL，那也可考虑使用0来进行代替。 创建表的时候定义好not null default 0。
    1.4. DATETIME和TIMESTAMP都能保持同样数据类型：日期和时间，精度为妙。而且TIMESTAMP使用的空间只是DATETIME的一半，TIMESTAMP使用4个字节，DATETIME使用8个字节。而且TIMESTAMP还能保存时区，拥有特殊的自动更新能力，但是TIMESTAMP的范围要比DATETIME要小的多。TIMESTAMP类型只能保存1970年1月1日零点到2038年。而DATETIME却能保存1001年到9999年。
  2. VARCHAR和CHAR
    2.1. 大家都知道VARCHAR是可变长度的，而CHAR是定长的。
    2.2. 使用VARCHAR(5)和VARCHAR（200）保存’hello’占用的空间都是一样的。但是VARCHAR(5)只会使用较小的内存空间，因为MySQL通常会分配固定大小的内存块来保存值。
  3. 索引对于查询的性能影响是非常大的。下面先介绍下索引类型。
    3.1. B-TREE索引，大部分MySQL存储引擎都支持B-TREE。除了ARCHIVE直到5.1才支持。
    3.1.1. 存储引擎使用了不同的方式把索引保存在磁盘上，它们会影响一定的性能。例如MyISAM使用前缀压缩以减少索引，而InnoDB不会压缩索引，因为它不能把压缩索引用于某些优化。
    3.1.2. B-TREE通常意味着存储是有序的。
    3.1.3. B-TREE索引能够很好的用户全键值，键值范围或者键前缀进行查找（最左前缀）。
    3.1.3.1. 匹配全名，如 where name=’timo’
    3.1.3.2. 匹配最左前缀， 如 where name like ‘tim%’
    3.1.3.3. 匹配范围值，如 where name between ‘tim’ and ‘timo’
    3.1.3.4. 精确匹配一部分并且匹配某个范围内的另一部分，如 where name=’timo’ and age between 25 and 30
    3.1.3.5. B-TREE索引通常能支持至访问索引的查询，它不会访问数据行
    3.1.4. B-TREE索引的局限性
    3.1.4.1. 假设有如下的索引 key(first_name, last_name, age)
    3.1.4.2. 如果查找没有从索引的最左边开始，它就没有什么用处。比如where first_name like ‘%mo’ 这样的查找是不走索引的。
    3.1.4.3. 不能跳过索引中的列, 如查找 where first_name=’timo’ and age = 25, 如果建立的是上面这样的联合索引，又跨了last_name，那就不会走索引了。
    3.1.4.4. 存储引擎不能优化访问任何在一个范围条件右边的列。如查找
    where first_name=’timo’ and last_name like ‘s%’ and age=25。访问就只能使用索引的前2列，因为like是范围条件。
    3.1.4.5. 一些局限并不是B-TREE固有的，而是MySQL查询优化器和存储引擎使用索引的方式造成的。
    3.2. 哈希索引(hash index)
    3.2.1. 它值对使用索引中的每一列的精确查找有用。所以很少用，在MySQL中是有Memory存储引擎支持显式的哈希索引。
    3.2.2. 由于hash index是给每个键值建立一个哈希表，所以它的查找速度是非常快的，但是也会有很多局限性。
    3.2.2.1. 因为索引只包含了哈希码和行指针，而不是指本身，MySQL不能使用索引中的值来避免读取行。
    3.2.2.2. 不能进行排序
    3.2.2.3. 不支持部分键匹配
    3.2.2.4. 只支持使用 =, in() 和<=>的相等比较。
    3.2.2.5. 发生碰撞的时候存储引擎必须访问链表中的每个指针，然后逐行进行数据比较，以确定正确的数据。
    3.2.2.6. 如果有很多碰撞，一些索引维护操作就会很慢。
    3.3. 空间（R-TREE）索引
    3.3.1. 只有MyISAM支持，可以使用GEOMETRY这样的地理空间数据类型，必须使用MySQL GIS函数进行查找。
    3.4. 全文索引
    3.4.1. 全文索引只有MyISAM支持。是从文本中直接找关键字，而不是从索引中进行比较。全文索引用户MATCH AGAINST操作。
    3.5. 高性能索引策略
    3.5.1. 隔离列
    3.5.1.1. 下面2条语句是不会使用索引的 
    1
    2
    3
    4
    5
    6
    7
    8
    9
    where actor_id + 1 = 5 where TO_DAYS(CURRENT_DATE) - TO_DAYS(date_col) <= 10 
    ```  
    3.5.1.2. 下面2条是针对上面2条进行修改使用索引的  
    ```sql 
    where actor_id = 4 where date_col >= DATE_SUB(CURRENT_DATE, INTERVAL 10 DAY) 
    ```  
    3.5.2. 前缀索引和索引选择性  
    3.5.2.1. 当某一列特别长的情况下，如果给全部长度建索引，那样会增加索引的大小，而只做很短的前缀索引，虽然节约了空间，但是会增加选择性。所以建前缀索引必须让选择性接近于全部长度的选择性。  
    3.5.2.2. 平均来说前缀的选择性能接近于0.31就可以了。
    sql select count(distinct city)/count() from db_name.table_name; select count(distinct left(city, 3))/count() AS sel3, count(distinct left(city, 4))/count(*) AS sel4 from db_name.table_name;
3.5.2.3. 只看平均选择率在特殊情况是不够的，比如在数据分布非常不均的情况下。  
3.5.2.4. Alter table db_name.table_name add KEY (city(7)) 这句就是只对city这一列的前7个字母进行索引。  
3.5.3. 聚集索引（clustered indexes）  
3.5.3.1. 在InnoDB中聚集索引实际上在同样的结构中保存了B-TREE索引和数据行。聚集的含义就是指实际的数据行和相关的键值保存在一起。每个表只能有一个聚集索引，因为不可能一次把行保存在两个地方  
3.5.3.2. 在MySQL中只有SolidDB和InnoDB是支持聚集索引的。  
3.5.3.3. InnoDB是按照主键（Primary Key）列进行聚集。如果没有定义主键，InnoDB会试着使用唯一的非空索引来代替。  
3.5.3.4. 聚集索引有助于性能，但是也会导致严重的性能问题。总的来说它有如下的优点：由于把索引和数据都保存在一棵B-TREE中，因此查找数据会比通常的要快。  
3.5.3.5. 聚集索引也有如下的缺点：会导致I/O密集，插入速度慢，更新索引列慢，插入新行会进行分页，这样导致占用更多的磁盘空间。第二索引会比预想的大，第二索引访问需要两次索引查找。  
3.5.3.6. 在InnoDB中是根据主键来进行顺序插入的（这个跟InnoDB的数据布局有关），所以主键最好是一个自增的值，与应用程序无关。  
3.5.4. 覆盖索引（covering indexes）  
3.5.4.1. 包含（或者覆盖）了所有满足查询需要的数据的索引叫覆盖索引。  
3.5.4.2. 索引记录通常远小于全行大小，因此只读取索引就能极大的减少数据访问量（这个跟聚集索引的优点一样）  
3.5.4.3. 索引是按照索引值进行排序的。  
3.5.4.4. 大部分存储引擎缓存索引比缓存数据更好（除了Falcon）。  
3.5.4.5. 对于InnoDB覆盖了查询的第二索引在主键中避免了另外一次索引查找。  
3.5.4.6. 覆盖索引必须保存它包含列的数据。  
3.5.4.7. 当发起一个索引覆盖的查询，用EXPLAIN会在extra列显示Using Index  
3.5.5. 为排序使用索引扫描  
3.5.5.1. MySQL有两种产生排序结果的方式，使用文件排序（Filesort）和扫描有序的索引。如果EXPLAIN的输入type列的值是index。那说明MySQL会扫描索引。  
3.5.5.2. 只有当索引的顺序和order by字句中的顺序完全一致，并且所有列排序的方向（升序或降序）一样才可以。如果查询连接多个表，只有在order by 字句的所有列引用的是第一个表才可以。  
3.5.5.3. 假设有如下表：  
```sql 
CREATE TABLE rental ( ………… PRIMARY KEY (rental_id), UNIQUE KEY rental_date (rental_date, inventory_id, customer_id), KEY idx_fx_inventory_id (inventory_id), KEY idx_fx_customer_id (customer_id), KEY idx_fx_staff_id (staff_id), ………… )

3.5.5.3.1. 下面的这几个语句是使用到索引的。 

WHERE rental_date='2010-05-02' ORDER BY inventory_id desc; WHERE rental_date > '2010-05-02' ORDER BY rental_date, inventory_id; 在where字句是范围的时候需要用最左前缀索引进行排序。
阅读全文 »
0%