月度归档:2014年07月

MySQL的简单使用笔记:增加实例以及启动

MySQL的简单使用笔记:增加实例以及启动

增加实例

增加实例这里指的的在源码编译安装完MySQL之后建立一个初始的数据库实例,占用某一端口,或者是使用新端口启动新的mysqld进程。

MySQL需要一些基础的数据库以及表来完成基本的设定,比如控制连接的mysql.user表:

在编译完成MySQL之后这些表是不存在的,需要通过安装目录下的script/mysql_install_db完成基础表的安装工作。

在这个脚本中完成安装工作所需要的参数至少需要如下几个:

  • basedir MySQL的安装目录
  • datadir MySQL实例的数据文件目录,比如数据库文件、socket文件等
  • user 安装MySQL时的设定的用户名

通过执行这一脚本,例如:

即完成了对MySQL的初始化操作,即完成了一个数据文件位于/usr/local/mysql/mysql_data/ 的数据库实例,通过使用不同的端口和目录,完成新增一个数据实例的工作。

启动

启动MySQL可以通过MySQL安装完成的mysqld_safe工具完成。

mysqld_safe脚本是推荐的启动MySQL的方式,其中特点是增加了一些安全保证的机制比如遇到错误重启并且写入日志(参数中的log-error指定位置)。

比较重要的个人认为是:

  • default-file 默认配置文件位置,如果使用这个参数,会通过默认文件获取配置,需要注意的是,如果需要使用,这个参数必须要放在第一个参数才能生效
  • basedir MySQL安装目录
  • datadir MySQL数据库的数据目录
  • user MySQL安装时配置的用户
  • pid-file pid文件位置
  • port 监听端口
  • socket 响应本地MySQL连接请求的socket文件位置

所有的参数事实上都会传送给mysqld,如果在配置文件(假设是/usr/local/mysql/my.cnf)中指明了MySQL的一切,则只需要使用简单的一句:

即可启动,同时也可以在参数中补齐缺失的项目。

后期计划整出一份MySQL启动所需最小配置参数列表。

其他

新增的数据库实例以及忘记密码的情况下需要通过mysqladmin工具完成密码的设定,需要指定数据库的数据socket连接文件位置以及用户名以及新的密码,例如:

还可以带上主机名:

以上。

纪念碑谷

纪念碑谷

这是一个由USTWO公司出品的冒险游戏,虽然闻名已久,但是自己却从来没有玩过这款游戏,直到这款游戏已经到达100w销量iOS版半价时才购入。

本来只是打算尝试一下,权当消遣,但是一开始游戏就被这个游戏征服了,方寸之间体现的那些让人惊奇的思路真是层出不穷;视角的转换经常能出现意想不到的结果,想起彭罗斯阶梯;同时拖动方块如同按下琴键,音效也是恰到好处……差一点就感动了,真是久(shao)未(jian)遇(duo)到(guai)这么精致的游戏了。

第一个故事

第一个故事

又一个故事

又一个故事

谁来帮助公主到达对岸?

谁来帮助公主到达对岸

自带BGM的石块表示让我来

自带BGM的石块表示让我来

乐声响起,小桥出现

乐声响起,小桥出现

无路可去?

无路可去?

另一个视角?

另一个视角?

空中走道

空中走道

为何而来

为何而来

为何而来

以上。

Vhost中目录不存在引起Apache不能启动

Vhost中目录不存在引起Apache不能启动

环境配置始终是工作过程中一个最为折腾人的环节,为了解决这个问题,最后写了个简单地装机脚本给大家使用。

环境配置包括软件的安装和设置的更改,一套LAMP每个组成部分设置都以百计,功能的强大的同时如果对每个部分的了解程度不足尤其容易出现一些看似很难以解决的问题,往往这些问题解决之后都会让人觉得沮丧不已。

今天配置环境出现了一个问题,就是只要在httpd.conf中添加了包含vhost设置的语句之后,Apache使用

apachectl -k gracecful

等方式启动时总会提示

httpd not running, trying to start

让人沮丧的是这种错误并没有打印error_log,同时使用语法检查也不能发现有任何错误,在逐句注释掉vhost中的设置语句之后,发现当注释掉所有提及的主机路径之后,居然可以重新启动了,于是检查发现这些目录都在主机上不存在,添加目录之后Apache能正常启动了。

尝试出来的结果,后面打算去找找更为具体的原因。

技术方案评审学习笔记

技术方案评审学习笔记

问题

作为初级工程师,技术方案评审是都会经历的过程之一吧。

工作了快一年,前期并没有做具体的业务,技术评审工作做的不多,等到完全切入业务之后才发现自己的设计在评审时不断的被挑战,压力很大。

解决这个问题目前看来只有多了解开源项目以及其他已有的类似项目的架构设计,但是短期之内要提升这个是比较困难的,而且目前参加了几次评审之后发现自己的方式并不是很正确。

后期自己思考了一下,首先还是改善技术评审的准备过程和具体的表达吧。

在这里记下几个评审过程中被大家提出的自己觉得目前比较靠谱的方法,如果理解有错,日后再慢慢修正。

解决

自己认为目前亟需注意的时评审过程中背景的代入,提出技术选型的原则,以及一些选型做法

背景

评审过程中没有项目的背景,对于评审的人员来说,完全不能了解具体的业务形态,最后直接会进入到技术细节之中,这个是没有意义的。

问题在于,自己直接上来说具体的实现细节,听众听着很枯燥乏味,并不能评估设计中选用方案是否合理,个人觉得这是大忌,原本技术评审就是为了确定是否当前方案在当前应用场景下是最好的方案,如果这点做不到,技术评审没有意义了。

讲述背景的时候,需要把整个项目的整个模块讲述清楚,对模块间的数据交换形式进行说明(比如文件
还是API还是Cache),刨除具体的实现细节,主要讲述数据流模块的划分,以及采用这一方式的应用场景相关信息。

选型原则

2.1 需要有至少两个方案

一个方案的评审不能叫做技术方案评审,A方案与B方案的对比才能更完备,甚至是A/B/C多个方案。方案多是为了从不同维度考虑问题,比如方案A注重性能,方案B注重开发难度,集中团队的思维力量来帮助自己这个初学者定下最好的选择。

2.2 舍弃本我的想法

对于初级工程师来说,方案的选择必须要有具体应用场景下案例的支撑。

初级工程师主要的设计方向还是套用具体方案到现有项目为主,同时对业务的应用场景要做一定的修改,这是由初级工程师的经验不足引起的问题,需要接受自己认识上的不足,同时借鉴前人的经验。

踩坑虽然要踩,但是错误的设计的坑自己觉得并不是值得去踩的。

2.3 容量决定设计

虽然需要考虑业务的发展壮大之后的压力,但是具体业务的实现过程中应该避免过度设计的问题。过度设计在业务量不能够做到足够大的情况下完全就是浪费人力。

根据产品经理提出的业务容量来确定自己的设计程度,但是设计一定要保证在产品经理定出的容量范围内做到高度可靠,可以做到超出1个请求就降级,但是设计上绝对不能在容量范围内不稳定。

2.4 方案的实现要有有根据

子模块使用的方案需要有根据,不能为了使用技术而使用技术。

同时要对选用方案的优势要清楚,需要具体到数值上,不能用感性的认识代替具体数字,数字有说服力,而感觉没有。

2.5 注意CAP原理

CAP三者注意取舍。

选型做法

3.1 准备数据

用数据佐证方案的可行性,比如性能提升比率,最大容量等等需要提前准备好。

了解线上资源的性能,比如DB的QPS,以及缓存的容量,或者网络带宽等等,估算出缓存命中率、数据大小等具体信息,将整个流程中的数据流动量估计好,支撑自己设计的合理性。

3.2 描述问题和解决方案

在陈述方案时,可以考虑通过问题-解决方案这样的描述方式进行,让评审同学了解如此设计的意义,同时判定是否合理。

3.3 选型对比

对比的技术方案要有侧重性以及使用场景,两个或者多个技术方案应该是为了解决项目不同方向上的问题为存在的,不是一个对比优劣的过程。

3.4 集中大家的智慧

接受大家汹涌的挑战吧~

可能很快自己就会觉得上面的做法不对,但是目前自己打算先这么一试吧。

以上。