solr主从复制的原理

master的工作

对于ReplicationHandler的复制功能来说,核心的问题确定是在一个时间点要复制哪些文件,这就用上了lucene的IndexDeletionPolicy的特性。

lucene在初始化时,会调用IndexDeletionPolicy.onInit(List commits)方法;
lucene在commit(触发的时机也可以是optimize、close,solr在commit时实际上就是close了indexwriter)时,会调用IndexDeletionPolicy.onInit(List commits)。

IndexCommit对象中保存了该次提交关联的文件列表等信息,这使得solr中的复制过程中,slave可以从master得到文件列表后跟本地文件做比较,跳过不变的文件,下载新文件,并删除无用的文件。

IndexDeletionPolicy的两个针对commits的函数,会对当前存在的commits列表做些处理,比如lucene默认的KeepOnlyLastCommitDeletionPolicy会只保留最新的IndexCommit,对那些过时的IndexCommit执行delete操作以将无用的文件删掉。

solr中,SolrDeletionPolicy默认也是保留最新一个IndexCommit,但可以设置maxCommitAge、maxCommitsToKeep、maxOptimizedCommitsToKeep来保留更多的IndexCommit。但solr真正使用的IndexDeletionPolicy实现是IndexDeletionPolicyWrapper,它是SolrDeletionPolicy的wrap。

在slave从master复制文件的过程中,要保证当前正在复制的IndexCommit点不能被删除,这就用到了IndexDeletionPolicyWrapper中的void setReserveDuration(Long indexVersion, long reserveTime)方法,该方法会在master向slave响应indexversion、filelist命令前、以及每向slave传送5M的索引文件内容时调用,而默认的reserveTime时间是10s,如果慢速网络传输5M数据需要10秒以上,就需要调整该值了。

ReplicationHandler复制文件没有采用rsync,而是使用http,它在读一个文件内容传输到slave时,默认是按照1M大小分段输出内容到slave(http chunked?),并且默认是对每段内容做了checksum,保证传输的内容的正确性。上面提到的setReserveDuration点,主要就是它在packetsWritten % 5 == 0次数后触发一次修改。

ReplicationHandler还可以备份索引文件。由于lucene的索引文件只是追加新文件而不会修改已有文件,所以只要针对一个IndexCommit点做备份,其过程还是很简单的。

slave的工作

slave启动时会创建SnapPuller对象,SnapPuller会启动一个线程定时的(pollInterval间隔)从master复制数据(fetchLatestIndex方法)。对于一次复制过程,slave和master交互处理细节如下:

1、slave首先向master询问最新的索引版本号(indexversion命令),slave检查得到的latestVersion、latestGeneration有效后,和本地的IndexCommit的getVersion()、getGeneration()比较,如果不相等,则需要往下进行,否则等待下一次调度。

2、slave向master请求之前得到的indexversion下的文件列表(filelist命令,包括索引文件和可选的配置文件)。如果文件列表为空,则返回等待下一次调度。否则,就需要检查哪些文件需要被下载过来。这里做的判断有:1)如果本地的commit.getGeneration() >= latestGeneration,说明本地索引文件被破坏(比如对slave不小心提交了修改索引的命令),需要完全将master的文件复制过来。2)逐个检查文件列表中的文件是否在本地存在,不存在就下载下来。

3、对于下载文件内容,对应命令是filecontent。下载的文件显然需要放到临时目录中,这个临时目录和已有的索引目录(默认名字index)在同一数据目录下,只是命名为index.<时间戳>。下载完毕后,copy数据有两种情况:
1)如果是完全下载,则不需要将临时目录中的文件copy到已有目录中,而是修改数据目录中的index.properties,标识索引目录为新生成的临时目录,而旧索引目录并不会被删除,可以手工删掉,当然,通常是不应该出现slave的Generation大于master的异常情况。
2)通常就是把临时索引目录的文件copy到旧索引目录,copy时要把segments_N放到最后copy,避免copy中途出现异常造成数据被毁。

4、当新索引和可选的配置文件copy完毕之后,slave会对solrcore的UpdateHandler做commit操作,这会close掉indexwriter并强制重启新的indexsearcher提供服务。同时,如果solrcore的UpdateHandler是DirectUpdateHandler2(不应该不是),会强制调用handler.forceOpenWriter()来删除旧的无用的索引文件,并调用replicationHandler.refreshCommitpoint()来更新slave的indexCommitPoint。

5、如果索引复制失败,slave会向数据目录下的replication.properties输出复制失败的信息。

时间: 2024-12-21 05:48:54

solr主从复制的原理的相关文章

Mysql中主从复制的原理、配置过程以及实际案例

Mysql中主从复制的原理.配置过程以及实际案例1.什么是主从复制?原理:主从分离,什么意思呢?我们不妨画个图看看.如图1所示: 2.准备工作:预备两台服务器,我这里使用虚拟机安装了两个Centos6.7_64位操作系统,并分别在两台服务器上安装mysql.我的IP地址分别为:192.168.1.15/192.168.1.16,这里我定义15为主服务器,16为从服务器.首先,我们编辑主服务器中mysql配置文件.(因我的mysql使用非root用户安装,因此配置文件放在/home/formal/

solr与.net系列课程(七)solr主从复制

solr与.net系列课程(七)solr主从复制    既然solr是解决大量数据全文索引的方案,由于高并发的问题,我们就要考虑solr的负载均衡了,solr提供非常简单的主从复制的配置方法,那么下面我们就来配置一下solr的主从复制 假设我们在192.168.0.8与192.168.0.9两台服务器上部署了solr服务,192.168.0.8作为主服务器,192.168.0.9作为从服务器, 首先配置主服务器找到C:\Program Files\Apache Software Foundati

redis之(十四)redis的主从复制的原理

一:redis主从复制的原理,步骤. 第一步:复制初始化 --->从redis启动后,会根据配置,向主redis发送SYNC命令.2.8版本以后,发送PSYNC命令. --->主redis收到SYNC命令后,开始在后台保存快照文件(即RDB持久化的过程),并将保存快照期间接收到的命令缓存起来. --->当主redis完成快照后,主redis会将快照文件和缓存命令发送给从redis.复制初始化结束. --->当主redis的复制初始化结束后,主redis每当收到写命令就会异步将写命令

solr与.net课程(七)solr主从复制

既然solr是解决大量数据全文索引的方案,因为高并发的问题,我们就要考虑solr的负载均衡了,solr提供很easy的主从复制的配置方法,那么以下我们就来配置一下solr的主从复制 如果我们在192.168.0.8与192.168.0.9两台server上部署了solr服务,192.168.0.8作为主server,192.168.0.9作为从server, 首先配置主server找到C:\Program Files\Apache Software Foundation\Tomcat 7.0\s

MySQL主从复制的原理及配置

[http://www.jb51.net/article/50053.htm] MySQL 数据库的高可用性架构: 集群,读写分离,主备.而后面两种都是通过复制来实现的.下面将简单介绍复制的原理及配置,以及一些常见的问题. [优点] 1. 如果主服务器出现问题, 可以快速切换到从服务器提供的服务2. 可以在从服务器上执行查询操作, 降低主服务器的访问压力3. 可以在从服务器上执行备份, 以避免备份期间影响主服务器的服务注意一般只有更新不频繁的数据或者对实时性要求不高的数据可以通过从服务器查询, 

MySQL GTID 主从复制的原理及配置

GTID是一个基于原始mysql服务器生成的一个已经被成功执行的全局事务ID,它由服务器ID以及事务ID组合而成.这个全局事务ID不仅仅在原始服务器器上唯一,在所有存在主从关系 的mysql服务器上也是唯一的.正是因为这样一个特性使得mysql的主从复制变得更加简单,以及数据库一致性更可靠.本文主要描述了快速配置一个基于GTID的主从复制架构,供大家参考. 一.GTID的概念 1.全局事务标识:global transaction identifiers. 2.GTID是一个事务一一对应,并且全

MySQL主从复制-GTID原理

一.MySQL 主从复制原理阐述 Mysql主从复制:简单来说就是Mysql 同步,Ab 复制等,主从复制是单向的,只能从 Master 复制到 Slave 上,延时基本上是毫秒级别的(排除网络延迟等问题).一组复制结构中可以有多个Slave,对于 Master一般场景推荐只有一个,[根据您的业务进行调配,主主复制.延迟复制等] Mysql 传统复制是基于 Mysql 二进制文件(Mysql-Bin.000001),加上对应日志文件中每个事件的偏移量位置点(Postion). MySQL主从复制

MySQL 主从复制及原理

1.主从复制配置a. 环境:CentOS7.4,IP地址分别是主库:192.168.11.146,从库:192.168.11.238,主库版本应低于或等于从库版本,这里用的都是MySQL 8.0.13b.主库配置/etc/my.cnf文件 [mysqld] #一般配置选项user=mysqlport=3306server_id=1basedir= /usr/local/mysqldatadir= /usr/app/mysqldata character_set_server=utf8 pid_f

solr全文检索实现原理

Solr是一个独立的企业级搜索应用服务器,它对外提供类似于Web-service的API接口.用户可以通过http请求,向搜索引擎服务器提交一定格式的XML文件,生成索引:也可以通过Http Get操作提出查找请求,并得到XML/Json格式的返回结果.采用Java5开发,基于Lucene. Lucene是apache软件基金会4 jakarta项目组的一个子项目,是一个开放源代码的全文检索引擎工具包,即它不是一个完整的全文检索引擎,而是一个全文检索引擎的架构,提供了完整的查询引擎和索引引擎,部