mysql主从配置

开启mysql只读模式:

FLUSH TABLES WITH READ LOCK;
SET GLOBAL read_only = 1;

查看主数据库状态:
show master status; //可以查看主mysql状态

备份主数据库:

mysqldump -h -ujbbwbu -p jbbwb > jbbwb.sql

导入备份文件到从数据库:

source jbbwb.sql

设置同步点:
change master to
-> master_host=’192.168.78.128′,
-> master_user=’test’,
-> master_password=’MyPass1!’,
-> master_log_file=’mysql-bin.000001′,
-> master_log_pos=1244;

start slave;

show slave status \G;

关闭mysql只读模式:
SET GLOBAL read_only = 0;
UNLOCK TABLES;

ubuntu清理磁盘空间

  1. df -h:显示磁盘占用

  2. apt-get autoclean:清理旧版本缓存

  3. apt-get clean:清理所有缓存

  4. apt-get autoremove:移除孤立软件(可以清理出500M+的空间)

  5. rm -rf /var/log/*:删除所有log(删了后last命令提示找不到一个/var/log下的文件。。。)

  6. find / -size +100M:列出所有大于100M的文件运行一遍后,把快照大小从3G+降到了2.5G,但相比我刚装好所有软件时的2.1G的快照还是大了蛮多

How to Read the PHP Slow Request Log

The PHP slow request log is where PHP records information about any request that takes more than five seconds to execute.

Having slow PHP code not only creates a bad experience for your site’s visitors, but it is also expensive for you. An app with fast PHP code only needs a single PHP process to handle many requests each second. However, since each PHP process can only execute one request at a time, when a PHP script is slow, the app needs additional PHP processes to handle the requests. Each additional process uses more memory, so having slow code means your server needs a lot more memory.

If your server has high memory usage or requests that are timing out, you may have slow requests that you can debug by reading the PHP slow request log.

Location of the PHP Slow Request Log

On the ServerPilot Business plan, you can view the PHP slow request log from each app’s Logs tab in ServerPilot.

If you’re not on the Business plan, you can SSH or SFTP into your server to view the PHP slow request log.

Each app has its own PHP slow request log. The log file is located under the app’s system user’s home directory at:

log/APPNAME/APPNAME_phpX.Y.slow.log

where phpX.Y is the PHP version the app is using, for example php7.0.

Understanding the PHP Slow Request Log

The PHP slow request log records stack traces (also known as tracebacks) of each slowly executing script at the moment the request passed five seconds in execution.

For example, an entry in the slow request log might look like this:

[06-Oct-2015 12:20:34]  [pool example] pid 1852
script_filename = /srv/users/serverpilot/apps/example/public/index.php
[0x00007f7e475ba138] curl_exec() /srv/users/serverpilot/apps/example/public/wp-content/plugins/wp-piwik/classes/WP_Piwik/Request/Rest.php:44
[0x00007f7e475b9f10] curl() /srv/users/serverpilot/apps/example/public/wp-content/plugins/wp-piwik/classes/WP_Piwik/Request/Rest.php:20
[0x00007f7e475b9d48] request() /srv/users/serverpilot/apps/example/public/wp-content/plugins/wp-piwik/classes/WP_Piwik/Request.php:63
[0x00007f7e475b9be0] perform() /srv/users/serverpilot/apps/example/public/wp-content/plugins/wp-piwik/classes/WP_Piwik.php:941
[0x00007f7e475b99f8] request() /srv/users/serverpilot/apps/example/public/wp-content/plugins/wp-piwik/classes/WP_Piwik.php:1098
[0x00007f7e475b98b8] updateTrackingCode() /srv/users/serverpilot/apps/example/public/wp-content/plugins/wp-piwik/classes/WP_Piwik/TrackingCode.php:16
[0x00007f7e475b9720] __construct() /srv/users/serverpilot/apps/example/public/wp-content/plugins/wp-piwik/classes/WP_Piwik.php:288
[0x00007fffa8cdcac0] addJavascriptCode() unknown:0
[0x00007f7e475b9540] call_user_func_array() /srv/users/serverpilot/apps/example/public/wp-includes/plugin.php:503
[0x00007f7e475b9428] do_action() /srv/users/serverpilot/apps/example/public/wp-includes/general-template.php:2284
[0x00007f7e475b9358] wp_footer() /srv/users/serverpilot/apps/example/public/wp-content/themes/k2/footer.php:17
[0x00007f7e475b9358] +++ dump failed

The first two lines tell you the time of the slow request and which script was initially requested. In the above example, these first two lines are:

[06-Oct-2015 12:20:34]  [pool example] pid 1852
script_filename = /srv/users/serverpilot/apps/example/public/index.php

The third line (the line immediately below the first two lines) is the top of the stack trace. This tells you the currently executing function at the time the script passed five seconds in execution. In the example above, the top of the stack trace is:

[0x00007f7e475ba138] curl_exec() /srv/users/serverpilot/apps/example/public/wp-content/plugins/wp-piwik/classes/WP_Piwik/Request/Rest.php:44

The three parts of this line are a unique identifier for the request ([0x00007f7e475ba138]), the name of the executing function (curl_exec()), and the file name and line number of that function (/srv/users/.../Request/Rest.php:44).

The top of the stack trace is generally the cause of your script’s slowness. The rest of the lines below that tell you each function call that led up to that point.

Note that you will sometimes see +++ dump failed at the bottom of a stack trace. That indicates the end of the stack trace and does not indicate a problem.

If you see a WordPress plugin name in the slow request log, you may be able to resolve your app’s slow request problems by disabling the plugin.

Common Causes of Slow Requests

There are a few common causes of slow requests.

Slow Requests Due to curl_exec()

If you see the curl_exec() function in your PHP slow request log, the problem is not a bug in cURL but rather that the request is taking a long time to complete.

When your scripts rely on making requests to external services and other websites, your own site can become slow and unreliable due to problems with the other website. For example, if their website is slow or is rate-limiting your requests, your own app will become very slow. These issues can be resolved by disabling plugins that make external requests and not writing your own PHP code to perform HTTP requests to external websites or services.

Slow Requests Due to mysqli_query()

If you see the mysqli_query() function in your PHP slow request log, the problem is not a bug in MySQL or any MySQL settings but rather that your PHP code is executing slow SQL queries.

You can have slow SQL queries due to, for example, lack of proper indexes in your database tables or PHP code that is inefficiently using the databases. The solution in this case is to track down the particular queries that are slow and fix them.

Acceptable Cases of Slow Requests

There is one acceptable case of slow requests where you can safely ignore entries in the PHP slow request log: slow requests that are not being performed when answering a website visitor’s request but rather are scheduled requests being performed in the background. Common example of such requests are requests for wp-cron.php or any requests you may have scheduled using cron.

pureComponent vs Component vs Stateless Functional component的区别

1,createClass,没有使用es6语法的时候,定义组件,就使用React.createClass来定义组件

var React = require("react");
var Greeting = React.createClass({
  
  propTypes: {
    name: React.PropTypes.string //属性校验
  },

  getDefaultProps: function() {
    return {
      name: 'Mary' //默认属性值
    };
  },
  
  getInitialState: function() {
    return {count: this.props.initialCount}; //初始化state
  },
  
  handleClick: function() {
    //用户点击事件的处理函数
  },

  render: function() {
    return <h1>Hello, {this.props.name}</h1>;
  }
});
module.exports = Greeting;

在createClass中,React对属性中的所有函数都进行了this绑定,也就是上面的handleClick其实相当于handleClick.bind(this);

2, component,因为es6对类和继承有语法级别的支持,所以用es6创建组件的方式更为优雅

import React from 'react';
class Greeting extends React.Component {

  constructor(props) {
    super(props); //调用父类的构造函数
    this.state = {count: props.initialCount};
    this.handleClick = this.handleClick.bind(this);
  }
  
  //static defaultProps = {
  //  name: 'Mary'  //定义defaultprops的另一种方式
  //}
  
  //static propTypes = {
    //name: React.PropTypes.string
  //}
  
  handleClick() {
    //点击事件的处理函数
  }
  
  render() {
    return <h1>Hello, {this.props.name}</h1>;
  }
}

Greeting.propTypes = {
  name: React.PropTypes.string
};

Greeting.defaultProps = {
  name: 'Mary'
};
export default Greating;

3,pureComponent
我们知道,当组件的props或者state发生变化时,React就会对当前的props和state分别与nextProps和nextState进行比较,当发生变化时,就会对当前组件或子组件进行重新渲染,否则就不渲染,有时候为了避免组件进行不必要的重新渲染,我们通过shouldComponentUpdate来优化性能

class CounterButton extends React.Component {
  constructor(props) {
    super(props);
    this.state = {count: 1};
  }

  shouldComponentUpdate(nextProps, nextState) {
    if (this.props.color !== nextProps.color) {
      return true;
    }
    if (this.state.count !== nextState.count) {
      return true;
    }
    return false;
  }

  render() {
    return (
      <button
        color={this.props.color}
        onClick={() => this.setState(state => ({count: state.count + 1}))}>
        Count: {this.state.count}
      </button>
    );
  }
}

shouldComponentUpdate通过判断props.color和state.count是否发生变化来重新渲染组件,React提供了PureComponent来自动帮我们做这件事,

class CounterButton extends React.PureComponent {
  constructor(props) {
    super(props);
    this.state = {count: 1};
  }

  render() {
    return (
      <button
        color={this.props.color}
        onClick={() => this.setState(state => ({count: state.count + 1}))}>
        Count: {this.state.count}
      </button>
    );
  }
}

4,Stateless Functional Component
上面提到的是用来创建包含状态和用户交互的复杂组件,当组件本身只是用来展示,所有数据都是通过props传入的时候,我们便可以使用Stateless Functional Component来快速创建组件

import React from 'react';
const Button = ({
  day,
  increment
}) => {
  return (
    <div>
      <button onClick={increment}>Today is {day}</button>
    </div>
  )
}

Button.propTypes = {
  day: PropTypes.string.isRequired,
  increment: PropTypes.func.isRequired,
}

选哪个
createClass, 除非你确实对ES6的语法一窍不通,不然的话就不要再使用这种方式定义组件。

Stateless Functional Component, 对于不需要内部状态,且用不到生命周期函数的组件,我们可以使用这种方式定义组件,比如展示性的列表组件,可以将列表项定义为Stateless Functional Component。

PureComponent/Component,对于拥有内部state,使用生命周期的函数的组件,我们可以使用二者之一,但是大部分情况下,我更推荐使用PureComponent,因为它提供了更好的性能,同时强制你使用不可变的对象,保持良好的编程习惯。

在Scala中case class

 1、初始化的时候可以不用new,当然你也可以加上,普通类一定需要加new;

 2、toString的实现更漂亮;

 3、默认实现了equals 和hashCode;

 4、默认是可以序列化的,也就是实现了Serializable ;

 5、自动从scala.Product中继承一些函数;

 6、case class构造函数的参数是public级别的,我们可以直接访问;

 7、支持模式匹配;
  其实感觉case class最重要的特性应该就是支持模式匹配。这也是我们定义case class的唯一理由,难怪Scala官方也说:It makes only sense to define case classes if pattern matching is used to decompose data structures.。

How do I find all files containing specific text on Linux?

Do the following:

grep -rnw '/path/to/somewhere/' -e 'pattern'
  • -r or -R is recursive,
  • -n is line number, and
  • -w stands for match the whole word.
  • -l (lower-case L) can be added to just give the file name of matching files.

Along with these, --exclude, --include, --exclude-dir flags could be used for efficient searching:

  • This will only search through those files which have .c or .h extensions:
    grep --include=\*.{c,h} -rnw '/path/to/somewhere/' -e "pattern"
    
  • This will exclude searching all the files ending with .o extension:
    grep --exclude=*.o -rnw '/path/to/somewhere/' -e "pattern"
    
  • For directories it’s possible to exclude a particular directory(ies) through --exclude-dirparameter. For example, this will exclude the dirs dir1/, dir2/ and all of them matching *.dst/:
    grep --exclude-dir={dir1,dir2,*.dst} -rnw '/path/to/somewhere/' -e "pattern"
    

This works very well for me, to achieve almost the same purpose like yours.

For more options check man grep.

Generate 16-digit unique code (like product serial)

static final private String ALPHABET = "ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";
final private Random rng = new SecureRandom();    

char randomChar(){
    return ALPHABET.charAt(rng.nextInt(ALPHABET.length()));
}

String randomUUID(int length, int spacing, char spacerChar){
    StringBuilder sb = new StringBuilder();
    int spacer = 0;
    while(length > 0){
        if(spacer == spacing){
            sb.append(spacerChar);
            spacer = 0;
        }
        length--;
        spacer++;
        sb.append(randomChar());
    }
    return sb;
}

使用webmagic构建一个分布式的爬虫

public class RedisScheduler implements Scheduler{

    private JedisPool pool;

    private static final String QUEUE_PREFIX = "queue_";

    private static final String SET_PREFIX = "set_";

    public RedisScheduler(String host){
        pool = new JedisPool(new JedisPoolConfig(), host);
    }

    @Override
    public void push(Request request, Task task) {
        Jedis jedis = pool.getResource();
          //使用SortedSet进行url去重
        if (jedis.zrank(SET_PREFIX+task.getUUID(),request.getUrl())==null){
            //使用List保存队列
            jedis.rpush(QUEUE_PREFIX+task.getUUID(),request.getUrl());
            jedis.zadd(SET_PREFIX+task.getUUID(),System.currentTimeMillis(),request.getUrl());
        }
    }

    @Override
    public Request poll(Task task) {
        Jedis jedis = pool.getResource();
        String url = jedis.lpop(QUEUE_PREFIX+task.getUUID());
            if (url==null) {
                return null;
            }
        return new Request(url);
    }
}

Hadoop YARN介绍

原文

YARN是Hadoop集群的资源管理系统。Hadoop2.0对MapReduce框架做了彻底的设计重构。YARN的基本设计思想是将MRv1中的JobTracker拆分成了两个独立的服务:一个全局的资源管理器ResourceManager每个应用程序特有的ApplicationMaster。其中ResourceManager负责整个系统的资源管理和分配,而ApplicationMaster负责单个应用程序的管理

YARN产生背景

MRv1的局限

YARN是在MRv1基础上演化而来的,它克服了MRv1中的各种局限性。在正式介绍YARN之前,先了解下MRv1的一些局限性,主要有以下几个方面:

  • 扩展性差。在MRv1中,JobTracker同时兼备了资源管理作业控制两个功能,这成为系统的一个最大瓶颈,严重制约了Hadoop集群扩展性。
  • 可靠性差。MRv1采用了master/slave结构,其中,master存在单点故障问题,一旦它出现故障将导致整个集群不可用。
  • 资源利用率低。MRv1采用了基于槽位的资源分配模型,槽位是一种粗粒度的资源划分单位,通常一个任务不会用完槽位对应的资源,且其他任务也无法使用这些空闲资源。此外,Hadoop将槽位分为Map Slot和Reduce Slot两种,且不允许它们之间共享,常常会导致一种槽位资源紧张而另外一种闲置(比如一个作业刚刚提交时,只会运行Map Task,此时Reduce Slot闲置)。
  • 无法支持多种计算框架。随着互联网高速发展,MapReduce这种基于磁盘的离线计算框架已经不能满足应用要求,从而出现了一些新的计算框架,包括内存计算框架、流式计算框架和迭代式计算框架等,而MRv1不能支持多种计算框架并存。

为了克服以上几个缺点,Apache开始尝试对Hadoop进行升级改造,进而诞生了更加先进的下一代MapReduce计算框架MRv2。正是由于MRv2将资源管理功能抽象成了一个独立的通用系统YARN,直接导致下一代MapReduce的核心从单一的计算框架MapReduce转移为通用的资源管理系统YARN。

集群资源统一管理

随着互联网的高速发展,新的计算框架不断出现,从支持离线处理的MapReduce,到支持在线处理的Storm,从迭代式计算框架Spark到流式处理框架S4,各种框架各有所长,各自解决了某一类应用问题。这时候就需要一个组件对同一个集群上的不同计算框架进行资源的统一管理。

YARN

相比于“一种计算框架一个集群”的模式,共享集群的模式存在多种好处:

  • 资源利用率高。如果每个框架一个集群,可能在某段时间内,有些计算框架的集群资源紧张,而另外一些集群资源空闲。共享集群模式则通过多种框架共享资源,使得集群中的资源得到更加充分的利用。
  • 运维成本低。如果采用“一个框架一个集群”的模式,则可能需要多个管理员管理这些集群,进而增加运维成本,而共享模式通常需要少数管理员即可完成多个框架的统一管理。
  • 数据共享。随着数据量的暴增,跨集群间的数据移动不仅需花费更长的时间,且硬件成本也会大大增加,而共享集群模式可让多种框架共享数据和硬件资源,将大大减小数据移动带来的成本。

YARN基本设计思想

MRv1主要由编程模型、数据处理引擎(由Map Task和Reduce Task组成)和运行时环境三部分组成。为了保证编程模型的向后兼容性,MRv2重用了MRv1中的编程模型和数据处理引擎,但运行时环境被完全重写。

MRv1的运行时环境主要由两类服务组成,分别是JobTracker和TaskTracker。其中,JobTracker负责资源管理作业控制。TaskTracker负责单个节点资源管理和任务执行

MRv1将资源管理和应用程序管理两部分混杂在一起,使得它在扩展性、容错性和多框架支持等方面存在明显缺陷。

而MRv2则通过将资源管理和应用程序管理两部分剥离开,分别由ResourceManager和ApplicationMaster负责,其中ResourceManager专管资源管理和调度,而ApplicationMaster则负责与具体应用程序相关的任务切分、任务调度和容错等,具体如下图所示。

Paste_Image.png

YARN基本架构

YARN是Hadoop 2.0中的资源管理系统,它的基本设计思想是将MRv1中的JobTracker拆分成了两个独立的服务:一个全局的资源管理器ResourceManager每个应用程序特有的ApplicationMaster。其中ResourceManager负责整个系统的资源管理和分配,而ApplicationMaster负责单个应用程序的管理

YARN总体上仍然是Master/Slave结构,在整个资源管理框架中,ResourceManager为Master,NodeManager为Slave,ResourceManager负责对各个NodeManager上的资源进行统一管理和调度。当用户提交一个应用程序时,需要提供一个用以跟踪和管理这个程序的ApplicationMaster,它负责向ResourceManager申请资源,并要求NodeManger启动可以占用一定资源的任务。由于不同的ApplicationMaster被分布到不同的节点上,因此它们之间不会相互影响。

下图描述了YARN的基本组成结构,YARN主要由ResourceManager、NodeManager、ApplicationMaster(图中给出了MapReduce和MPI两种计算框架的ApplicationMaster,分别为MR AppMstr和MPI AppMstr)和Container等几个组件构成。

YARN基本架构

接下来对YARN里几个重要的组件一一介绍。

1. ResourceManager(RM)

RM是一个全局的资源管理器,负责整个系统的资源管理和分配。它主要由两个组件构成:调度器(Scheduler)和应用程序管理器(Applications Manager,ASM)。

(1)调度器(分配Container)

调度器根据容量、队列等限制条件(如每个队列分配一定的资源,最多执行一定数量的作业等),将系统中的资源分配给各个正在运行的应用程序。需要注意的是,该调度器是一个“纯调度器”,它不再从事任何与具体应用程序相关的工作,比如不负责监控或者跟踪应用的执行状态等,也不负责重新启动因应用执行失败或者硬件故障而产生的失败任务,这些均交由应用程序相关的ApplicationMaster完成。调度器仅根据各个应用程序的资源需求进行资源分配,而资源分配单位用一个抽象概念“资源容器”(Resource Container,简称Container)表示,Container是一个动态资源分配单位,它将内存、CPU、磁盘、网络等资源封装在一起,从而限定每个任务使用的资源量。此外,该调度器是一个可插拔的组件,用户可根据自己的需要设计新的调度器,YARN提供了多种直接可用的调度器,比如Fair Scheduler和Capacity Scheduler等。

(2)应用程序管理器

应用程序管理器负责管理整个系统中所有应用程序,包括应用程序提交、与调度器协商资源以启动ApplicationMaster、监控ApplicationMaster运行状态并在失败时重新启动它等。

2. ApplicationMaster(AM)

用户提交的每个应用程序均包含一个AM,主要功能包括:

  • 与RM调度器协商以获取资源(以Container表示)
  • 将得到的任务进一步分配给内部的任务
  • 与NM通信以启动/停止任务
  • 监控所有任务运行状态,并在任务失败时重新为任务申请资源以重启任务

3. NodeManager(NM)

NM是每个节点上的资源和任务管理器。一方面,它定时地向RM汇报本节点的资源使用情况和Container运行状态;另一方面,它接受并处理来自AM的Container启动/停止等各种请求。

4. Container

Container是YARN中的资源抽象,它封装了某个节点上的多维资源,如CPU、内存、磁盘、网络等。当AM向RM申请资源时,RM向AM返回的资源便是用Container表示的。YARN会为每个任务分配一个Container,且该任务只能使用该Container中描述的资源。Container是一个动态资源划分单位,是根据应用程序的需求自动生成的。目前,YARN仅支持CPU和内存两种资源。

YARN工作流程

运行在YARN上的应用程序主要分为两类:短应用程序和长应用程序。其中,短应用程序是指一定时间内可运行完成并正常退出的应用程序,如MapReduce作业、Spark DAG作业等。长应用程序是指不出意外,永不终止运行的应用程序,通常是一些服务,比如Storm Service(包括Nimbus和Supervisor两类服务),HBase Service(包括HMaster和RegionServer两类服务)等,而它们本身作为一种框架提供编程接口供用户使用。尽管这两类应用程序作业不同,一类直接运行数据处理程序,一类用于部署服务(服务之上再运行数据处理程序),但运行在YARN上的流程是相同的。

当用户向YARN中提交一个应用程序后,YARN将分两个阶段运行该应用程序:第一阶段是启动ApplicationMaster。第二阶段是由ApplicationMaster创建应用程序,为它申请资源,并监控它的整个运行过程,直到运行完成。具体如下:

  1. 用户向YARN中提交应用程序,其中包括ApplicationMaster程序、启动ApplicationMaster的命令、用户程序等。
  2. ResourceManager为该应用程序分配第一个Container,并与对应的NodeManager通信,要求它在这个Container中启动应用程序的ApplicationMaster。
  3. ApplicationMaster首先向ResourceManager注册,这样用户就可以直接通过ResourceManager查看应用程序的运行状态,然后它将为各个任务申请资源,并监控它的运行状态,直到运行结束,即重复步骤4~7。
  4. ApplicationMaster采用轮询的方式通过RPC协议向ResourceManager申请和领取资源。
  5. 一旦ApplicationMaster申请到资源后,便与对应的NodeManager通信,要求它启动任务。
  6. NodeManager为任务设置好运行环境(包括环境变量、JAR包、二进制程序等)后,将任务启动命令写到一个脚本中,并通过运行该脚本启动任务。
  7. 各个任务通过某个RPC协议向ApplicationMaster汇报自己的状态和进度,以让ApplicationMaster随时掌握各个任务的运行状态,从而可以在任务失败时重新启动任务。
  8. 应用程序运行完成后,ApplicationMaster向ResourceManager注销并关闭自己。

YARN工作流程