摘要:Indexing Service - OpenQuery()

本文介绍了如何使用SQLServer的OPENQUERY函数查询IndexServer,详细解释了查询语法、可用属性及特殊谓词MATCHES和ARRAY的使用方法。
摘要:Indexing Service - OpenQuery()
2007年12月26日 星期三 上午 09:50
  通过SQL Server查询Index Server
  如果要通过SQL Server查询Index Server,须使用OPENQUERY函数。其语法结构如下。
  OPENQUERY(linked_server, 'query')
  其中linked_server参数为连接的名称。而query参数为要进行的查询,它将以一个字符串的形式传送给OPENQUERY函数。此函数返回的将是一个虚拟表,从而可以让我们对其做进一步的查询。
  
  下面的语句查找内容包含中SQL这个单词的所有文件:
  SELECT *
  FROM OpenQuery(FileSystem,
  'SELECT Directory, FileName, DocAuthor, Size, Create
  FROM SCOPE()
  WHERE CONTAINS( Contents, ''SQL'' ) ' )
  对于Index Server的查询,其FROM语句的语法格式于普通的SQL语句是有所区别的。其语法结构如下:
  FROM [ Catalog_Name.. ] { SCOPE( [ 'Scope_Arguments' ] ) }
  其中的Catalog_Name参数用于指明要进行查询的索引目录。由于我们在定义连接时只能选择一个索引目录,所以此参数在此将被省略。而SCOPE函数用于指明要进行查询的文件所在的目录。SCOPE函数的语法结构如下图所示。
  
  其中DEEP TRAVERSAL OF关键字指明将查询目录中所有的文件,包括其子目录中的所有文件。而SHALLOW TRAVERSAL OF关键字则指明只查询顶级目录中的文件,而不包括子目录中的那些文件。如果不指明查询的目录深度,则默认为DEEP TRAVERSAL OF。
  physical_path和virtual_directory分别为物理目录和虚拟目录。其中各自的含义在图中已经标示的非常明白了,在此就不再进一步说明了。
  Index Server共支持50种文件属性,而可以用来作为查询条件或返回结果的常用文件属性:
  
  属性名称 数据类型 注释 可否用于ORDER BY子句 可否用于SELECT语句中
  Access datetime 文件的最后访问时间。 可 可
  Characterization nvarchar或ntext 文档的描述或摘要,由Index Server使用。 否 可
  Create datetime 文件的创建时间。 可 可
  Directory Nvarchar 文件的物理路径,不包含文件名。 可 可
  DocAppName nvarchar 创建文件的应用程序的名称。如Microsoft Word 9.0。 可 可
  DocAuthor nvarchar 文档的作者。 可 可
  DocComments nvarchar 关于文档的注释。 可 可
  DocCompany nvarchar 写作文档的公司的名称。 可 可
  DocLastAuthor nvarchar 最近编辑文档的用户。 可 可
  DocLastPrinted datetime 文档的最近一次打印时间。 可 否
  DocPageCount integer 文档的页数。 可 否
  DocParaCount integer 文档的图形数量。 可 否
  DocRevNumber integer 文档的当前版本。 可 可
  DocSubject nvarchar 文档的主题。 可 可
  DocTemplate nvarchar 文档的模板。 可 可
  DocTitle nvarchar 文档的标题。 可 可
  DocWordCount integer 文档的字数。 可 否
  FileIndex Decimal(19,0) 文件的唯一标识。 可 可
  FileName nvarchar 文件名。 可 可
  HitCount integer 文件中的命中次数(单词匹配查询)。即文件中有多少个查询条件中的单词。 可 可
  Path nvarchar 文件的物理路径,包含文件名。 可 可
  Rank integer 行的等级,范围从 0 到 1000,数字越大表示越匹配。 可 可
  ShortFileName nvarchar 短文件名(8.3格式)。 可 可
  Size Decimal(19,0) 文件大小,单位是字节。 可 可
  VPath nvarchar 指向文件的完整虚拟路径,包括文件名。如果有多个可能的路径,将选择最符合查询的一个。 可 可
  Write datetime 最近一次写文件的时间。 可 可
  
  可以在Where子句中使用以上各种属性作为查询的条件。当条件中包含全文检索条件时,需要使用CONTAINS和FREETEXT语句,其用法同SQL Server的全文检索相同。要注意的是,在对Index Server的查询中,不能使用GROUP BY和HAVING子句。因为这不被Index Server所支持。
  此外,在查询的SELECT子句中,不能使用*来选择所有的属性。*只有在对视图进行查询时才可以使用。视图实际上可以理解为从一个查询导出的虚拟表。通过对视图的查询,可以实现对查询结果的再次查询。视图一般应用于需要经常被其他查询作为FROM子句中的数据源时使用。建立视图使用CREATE VIEW语句,其语法结构如下:
  CREATE VIEW view_name [(column ][,...n])]
  AS
  
  select_statement
  其中view_name为要建立的视图的名称,而AS子句后面的就是建立视图的查询语句。而此语句有以下限制:不能包含ORDER BY、COMPUTE和COMPUTE BY等子句;不能包含INTO关键字;不能涉及临时表。
  而column则用于为视图中的各个字段命名。一般只有在这些字段是表达式或函数及常数时才需要为其命名。
  在SQL Server中,也同样可以使用CREATE VIEW语句来建立视图。
  下面我们通过一个例子来了解对Index Server查询的全部过程。
  我们将在虚拟目录/Corpus和C:/temp目录中查找那些作者在writer表中存在记录且文档字数超过5000字的文件。并返回作者的名字、文档题目以及作者的身份。其查询语句和具体操作过程如下图所示。
  
  Index Server查询过程
  其中各个步骤的解释如下:
  1:查询被提交到SQL Server,将分布式查询部分(包含在OPENQUERY函数之内的部分)传递给SQL Server分布式查询处理器。
  2:分布式查询处理器将查询进一步传递给OLE DB Provider for Indexing Service(MSIDXS),由MSIDX连接到文件系统。
  3:MSIDXS分析查询语句并向文件索引服务发出相应的命令。
  4:文件索引服务从一个结合了Web虚拟目录/Corpus和C:/Temp目录的虚拟表中查找那些符合条件的文件并将其作为一个行集返回给MSIDX。
  5:MSIDXS将行集返回给分布式查询处理器。
  6:分布式查询处理器将返回的行集作为一个表同writers表进行结合查询,并将最终结果返回给查询提交者。
  
  在对Index Server的查询中,还不能使用QUANTIFIED、COMPARISON、BETWEEN、EXISTS、IN以及NULL等谓词。因为这些都不被Index Server所支持。但是它支持两个SQL Server所不直接支持的两个谓词:MATCHES和ARRAY。我们可以在对Index Server的查询语句中使用它们。其含义和语法结构分别如下:
  MATCHES:用于模式匹配,其作用同Like相近但是功能更为强大。它的语法结构如下:MATCHES (Column_Reference, ' { Grouped_Search_Pattern | Counted_Search_Pattern } ') > 0
  其中Column_Reference为指定的文件属性,其数据类型必须同后面的Grouped_Search_Pattern相匹配。
  Grouped_Search_Pattern为指定的匹配模式。而Counted_Search_Pattern则用于对匹配的数量进行限定,可以有三种限定方式:
  严格匹配:在查询的文件属性中包含指定数目的满足匹配条件的字串。
  至少匹配:在查询的文件属性中包含大于或等于指定数目的满足匹配条件的字串。
  范围匹配:在查询的文件属性中包含满足匹配条件的字串数目界于n~m之间。
  MATCHES可以使用的模式匹配符及其含义见下表:
  
  符号 描述
  * 包含指定的匹配字符串同时还包含其他0个或更多的字符。这同dir命令中使用的*十分类似。如以b开头,以d结尾的字符串的匹配条件为b|*d。
  ? 包含指定的匹配字符串同时还包含其他0个或一个字符。如满足b|?d匹配条件的字串包括bd、bad和bed等。
  + 包含指定的匹配字符串同时还包含其他1个或更多的字符。如满足b|+d匹配条件的字串包括bad、bed和bond等。
  ( ) 用于界定模式匹配,表明在其中的是模式匹配字符条件。当条件多于一个时使用。
  { } 用于界定匹配数量,表明在其中的是模式匹配数量条件。
  [ ] 用来在模式条件中指明一个字符串的范围。
  | 一个转义符,要求在上面的每个符号前使用它。从而将其同普通字符区别开来。
  下面通过几个简单的例子来说明MATCHES谓词的使用方法。
  查找文件内容中出现"SQL"三次的文件:
  ...WHERE MATCHES (DocText, '|(SQL|)|{3|}' ) > 0
  查找文件内容中出现"SQL"三次以上的文件:
  ...WHERE MATCHES (DocText, '|(SQL|)|{3,|}' ) > 0
  查找文件内容中出现"SQL"三次到十次之间的文件:
  ...WHERE MATCHES (DocText, '|(Bora|)|{3,10|}' ) > 0
  当你不能确定作者姓名中包含"Pellow"还是"Pelow"时,可以使用下面的条件语句:
  ...WHERE MATCHES( DocAuthor, '* Pel|{1,2|}ow' ) > 0
  ARRAY:用于在两个排列(也称为矢量)之间通过逻辑运算符来进行比较。其语法结构如下:
  
  Column_Reference Comparison_Operator [ ALL | SOME ] ARRAY [ Array_Elements ]
  其中Column_Reference用于比较的文件属性,可以是多个属性。但是要求其数据类型同后面的Array_Elements相匹配。
  Comparison_Operator为比较运算符,它可以是=、!=(不等于)、>、=>、<、<=。
  Array_Elements用于指明用于进行比较的排列,其必须用"[]"括起来。空的排列也是允许的,比如下面的查询也是合法的。
  SELECT foo FROM SCOPE() WHERE bar = ARRAY[]
  ALL和SOME则用来指明对Array_Elements使用不同的比较方式。对于All,将会对左侧排列中的每个元素同右侧排列中相应的元素进行比较。比如下面的表达式对于ALL,表达式结果为假:
  [1,2,3] > ALL ARRAY [1,2]
  而对于SOME,则只要在左侧排列中有一个值同右侧排列中所有的值比较复合条件即可。因此下面的表达式对于SOME,其表达式结果为真:
  [1,2,3] > SOME ARRAY [2,1]
  因为在左侧排列中的3,比右侧排列中的2和1都大因此返回值为真。

 

根据日志获取服务不可用阶段Build 湘雅三GCP(生产环境) - dockerbuild - Default Job #83 (GCPXY3-DOC-JOB1-83) started building on agent Local Agent1, bamboo version: 8.1.1 simple 12-Aug-2025 17:57:36 Local Agent1 simple 12-Aug-2025 17:57:36 Build working directory is /var/atlassian/application-data/bamboo/local-working-dir/622593/GCPXY3-DOC-JOB1 simple 12-Aug-2025 17:57:36 Executing build 湘雅三GCP(生产环境) - dockerbuild - Default Job #83 (GCPXY3-DOC-JOB1-83) simple 12-Aug-2025 17:57:36 Running pre-build action: VCS Version Collector simple 12-Aug-2025 17:57:36 Running pre-build action: Build Log Labeller Pre Build Action command 12-Aug-2025 17:57:36 Substituting variable: ${bamboo.prod_xy3} with 119.91.104.191 simple 12-Aug-2025 17:57:36 Starting task 'SSH Task' of type 'com.atlassian.bamboo.plugins.bamboo-scp-plugin:sshtask' simple 12-Aug-2025 17:57:36 Connecting to 119.91.104.191 on port: 2022 simple 12-Aug-2025 17:57:37 Executing [ simple 12-Aug-2025 17:57:37 cd /opt/xy3/binaries/ simple 12-Aug-2025 17:57:37 docker-compose -f docker-compose-web-prod.yml up -d --build --force-recreate ghc-web simple 12-Aug-2025 17:57:37 docker-compose -f docker-compose-prod.yml up -d --build --force-recreate ctms-auth-prod simple 12-Aug-2025 17:57:37 docker-compose -f docker-compose-prod.yml up -d --build --force-recreate ctms-gateway-prod simple 12-Aug-2025 17:57:37 docker-compose -f docker-compose-prod.yml up -d --build --force-recreate ctms-system-prod simple 12-Aug-2025 17:57:37 docker-compose -f docker-compose-prod.yml up -d --build --force-recreate ctms-irbs-prod simple 12-Aug-2025 17:57:37 simple 12-Aug-2025 17:57:37 docker system prune -f simple 12-Aug-2025 17:57:37 ] build 12-Aug-2025 18:00:09 Step 1/6 : FROM java:8 build 12-Aug-2025 18:00:09 ---> d23bdf5b1b1b build 12-Aug-2025 18:00:09 Step 2/6 : VOLUME /tmp build 12-Aug-2025 18:00:09 ---> Using cache build 12-Aug-2025 18:00:09 ---> 65ebb77cad09 build 12-Aug-2025 18:00:09 Step 3/6 : ARG version build 12-Aug-2025 18:00:09 ---> Using cache build 12-Aug-2025 18:00:09 ---> 227aa09399d2 build 12-Aug-2025 18:00:09 Step 4/6 : ARG app build 12-Aug-2025 18:00:09 ---> Using cache build 12-Aug-2025 18:00:09 ---> 81b3499de399 build 12-Aug-2025 18:00:09 Step 5/6 : COPY services/${version}/lib/${app}/ ./lib/ build 12-Aug-2025 18:00:09 ---> Using cache build 12-Aug-2025 18:00:09 ---> 1e7dd4b95377 build 12-Aug-2025 18:00:09 Step 6/6 : ADD services/${version}/${app}.jar ${app}.jar build 12-Aug-2025 18:00:15 ---> cab7592fa7f9 build 12-Aug-2025 18:00:15 build 12-Aug-2025 18:00:17 Successfully built cab7592fa7f9 build 12-Aug-2025 18:00:17 Successfully tagged ctms-auth-prod:1.0.0 build 12-Aug-2025 18:02:14 Step 1/6 : FROM java:8 build 12-Aug-2025 18:02:15 ---> d23bdf5b1b1b build 12-Aug-2025 18:02:15 Step 2/6 : VOLUME /tmp build 12-Aug-2025 18:02:15 ---> Using cache build 12-Aug-2025 18:02:15 ---> 65ebb77cad09 build 12-Aug-2025 18:02:15 Step 3/6 : ARG version build 12-Aug-2025 18:02:15 ---> Using cache build 12-Aug-2025 18:02:15 ---> 227aa09399d2 build 12-Aug-2025 18:02:15 Step 4/6 : ARG app build 12-Aug-2025 18:02:15 ---> Using cache build 12-Aug-2025 18:02:15 ---> 81b3499de399 build 12-Aug-2025 18:02:15 Step 5/6 : COPY services/${version}/lib/${app}/ ./lib/ build 12-Aug-2025 18:02:16 ---> Using cache build 12-Aug-2025 18:02:16 ---> 9036f99d9220 build 12-Aug-2025 18:02:16 Step 6/6 : ADD services/${version}/${app}.jar ${app}.jar build 12-Aug-2025 18:02:29 ---> 7cdc7da77ff7 build 12-Aug-2025 18:02:29 build 12-Aug-2025 18:02:30 Successfully built 7cdc7da77ff7 build 12-Aug-2025 18:02:30 Successfully tagged ctms-gateway-prod:1.0.0 build 12-Aug-2025 18:04:17 Step 1/6 : FROM java:8 build 12-Aug-2025 18:04:18 ---> d23bdf5b1b1b build 12-Aug-2025 18:04:18 Step 2/6 : VOLUME /tmp build 12-Aug-2025 18:04:18 ---> Using cache build 12-Aug-2025 18:04:18 ---> 65ebb77cad09 build 12-Aug-2025 18:04:18 Step 3/6 : ARG version build 12-Aug-2025 18:04:18 ---> Using cache build 12-Aug-2025 18:04:18 ---> 227aa09399d2 build 12-Aug-2025 18:04:18 Step 4/6 : ARG app build 12-Aug-2025 18:04:18 ---> Using cache build 12-Aug-2025 18:04:18 ---> 81b3499de399 build 12-Aug-2025 18:04:18 Step 5/6 : COPY services/${version}/lib/${app}/ ./lib/ build 12-Aug-2025 18:04:18 ---> Using cache build 12-Aug-2025 18:04:18 ---> aa994c85a058 build 12-Aug-2025 18:04:18 Step 6/6 : ADD services/${version}/${app}.jar ${app}.jar build 12-Aug-2025 18:04:27 ---> 52ea93d68a7c build 12-Aug-2025 18:04:27 build 12-Aug-2025 18:04:28 Successfully built 52ea93d68a7c build 12-Aug-2025 18:04:28 Successfully tagged ctms-system-prod:1.0.0 build 12-Aug-2025 18:06:09 Step 1/6 : FROM java:8 build 12-Aug-2025 18:06:10 ---> d23bdf5b1b1b build 12-Aug-2025 18:06:10 Step 2/6 : VOLUME /tmp build 12-Aug-2025 18:06:10 ---> Using cache build 12-Aug-2025 18:06:10 ---> 65ebb77cad09 build 12-Aug-2025 18:06:10 Step 3/6 : ARG version build 12-Aug-2025 18:06:10 ---> Using cache build 12-Aug-2025 18:06:10 ---> 227aa09399d2 build 12-Aug-2025 18:06:10 Step 4/6 : ARG app build 12-Aug-2025 18:06:11 ---> Using cache build 12-Aug-2025 18:06:11 ---> 81b3499de399 build 12-Aug-2025 18:06:11 Step 5/6 : COPY services/${version}/lib/${app}/ ./lib/ build 12-Aug-2025 18:06:12 ---> Using cache build 12-Aug-2025 18:06:12 ---> 06af45c2f79d build 12-Aug-2025 18:06:12 Step 6/6 : ADD services/${version}/${app}.jar ${app}.jar build 12-Aug-2025 18:06:23 ---> d28fed9c95a3 build 12-Aug-2025 18:06:23 build 12-Aug-2025 18:06:24 Successfully built d28fed9c95a3 build 12-Aug-2025 18:06:24 Successfully tagged ctms-irbs-prod:1.0.0 build 12-Aug-2025 18:06:26 Deleted Images: build 12-Aug-2025 18:06:26 deleted: sha256:b5ba06737e2e551082b8096fbc83ce3675dac3ccfd413b9fe1b15121fbf97cf9 build 12-Aug-2025 18:06:26 deleted: sha256:35c76628a0ea6c92bf3f1e23a65d39b65cb9cfaf83af57df5293573bff5b944f build 12-Aug-2025 18:06:26 deleted: sha256:904ebc147f8ad93396e7ee55cb978baf913c7a9934b2249d22da7c798f15f5c1 build 12-Aug-2025 18:06:26 deleted: sha256:6587fc1c0e72fe65af594441b34436d18df5546688aa564f1419dfa50b022112 build 12-Aug-2025 18:06:26 deleted: sha256:1c8813bff1f6ce731675cf4229211dd4bf3421e7548792cf7657591a970494ac build 12-Aug-2025 18:06:26 deleted: sha256:16b2e7700101600360923d8b05101ff56e06d8da0928ef41edbf2b3f7a68c30c build 12-Aug-2025 18:06:26 deleted: sha256:943137eae2d76ad2baa2753da688278509d17f3b13c36b819dd66126db3db594 build 12-Aug-2025 18:06:26 deleted: sha256:ad52f9ba3affa27cdfc761c46ee7233344dae05480051f6f00da31088f608174 build 12-Aug-2025 18:06:26 build 12-Aug-2025 18:06:26 Total reclaimed space: 24.83MB error 12-Aug-2025 18:06:26 Found orphan containers (ghc-nacos, ctms-irbs-prod, ghc-minio, ctms-auth-prod, ctms-system-prod, ctms-gateway-prod, ghc-mysql, ghc-mysql2, ghc-redis) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up. error 12-Aug-2025 18:06:26 Recreating ghc-web ... error 12-Aug-2025 18:06:26  error 12-Aug-2025 18:06:26 Recreating ghc-web ... done error 12-Aug-2025 18:06:26 Found orphan containers (ghc-mysql, ghc-minio, ghc-web, ghc-mysql2, ghc-nacos, ghc-redis) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up. error 12-Aug-2025 18:06:26 Building ctms-auth-prod error 12-Aug-2025 18:06:26 Recreating ctms-auth-prod ... error 12-Aug-2025 18:06:26  error 12-Aug-2025 18:06:26 Recreating ctms-auth-prod ... done error 12-Aug-2025 18:06:26 Found orphan containers (ghc-mysql, ghc-web, ghc-mysql2, ghc-nacos, ghc-minio, ghc-redis) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up. error 12-Aug-2025 18:06:26 Building ctms-gateway-prod error 12-Aug-2025 18:06:26 Recreating ctms-gateway-prod ... error 12-Aug-2025 18:06:26  error 12-Aug-2025 18:06:26 Recreating ctms-gateway-prod ... done error 12-Aug-2025 18:06:26 Found orphan containers (ghc-redis, ghc-nacos, ghc-web, ghc-mysql2, ghc-mysql, ghc-minio) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up. error 12-Aug-2025 18:06:26 Building ctms-system-prod error 12-Aug-2025 18:06:26 Recreating ctms-system-prod ... error 12-Aug-2025 18:06:26  error 12-Aug-2025 18:06:26 Recreating ctms-system-prod ... done error 12-Aug-2025 18:06:26 Found orphan containers (ghc-mysql2, ghc-redis, ghc-nacos, ghc-mysql, ghc-minio, ghc-web) for this project. If you removed or renamed this service in your compose file, you can run this command with the --remove-orphans flag to clean it up. error 12-Aug-2025 18:06:26 Building ctms-irbs-prod error 12-Aug-2025 18:06:26 Recreating ctms-irbs-prod ... error 12-Aug-2025 18:06:26  error 12-Aug-2025 18:06:26 Recreating ctms-irbs-prod ... done error 12-Aug-2025 18:06:26  simple 12-Aug-2025 18:06:26 [ simple 12-Aug-2025 18:06:26 cd /opt/xy3/binaries/ simple 12-Aug-2025 18:06:26 docker-compose -f docker-compose-web-prod.yml up -d --build --force-recreate ghc-web simple 12-Aug-2025 18:06:26 docker-compose -f docker-compose-prod.yml up -d --build --force-recreate ctms-auth-prod simple 12-Aug-2025 18:06:26 docker-compose -f docker-compose-prod.yml up -d --build --force-recreate ctms-gateway-prod simple 12-Aug-2025 18:06:26 docker-compose -f docker-compose-prod.yml up -d --build --force-recreate ctms-system-prod simple 12-Aug-2025 18:06:26 docker-compose -f docker-compose-prod.yml up -d --build --force-recreate ctms-irbs-prod simple 12-Aug-2025 18:06:26 simple 12-Aug-2025 18:06:26 docker system prune -f simple 12-Aug-2025 18:06:26 ] has finished. simple 12-Aug-2025 18:06:26 Result: exit code = 0 simple 12-Aug-2025 18:06:26 Finished task 'SSH Task' with result: Success simple 12-Aug-2025 18:06:26 Running post build plugin 'NCover Results Collector' simple 12-Aug-2025 18:06:26 Running post build plugin 'Artifact Copier' simple 12-Aug-2025 18:06:26 Running post build plugin 'npm Cache Cleanup' simple 12-Aug-2025 18:06:26 Running post build plugin 'Build Results Label Collector' simple 12-Aug-2025 18:06:26 Running post build plugin 'Clover Results Collector' simple 12-Aug-2025 18:06:26 Running post build plugin 'Docker Container Cleanup' simple 12-Aug-2025 18:06:26 Finalising the build... simple 12-Aug-2025 18:06:26 Stopping timer. simple 12-Aug-2025 18:06:26 Build GCPXY3-DOC-JOB1-83 completed. simple 12-Aug-2025 18:06:26 Running on server: post build plugin 'NCover Results Collector' simple 12-Aug-2025 18:06:26 Running on server: post build plugin 'Build Hanging Detection Configuration' simple 12-Aug-2025 18:06:26 Running on server: post build plugin 'Build Labeller' simple 12-Aug-2025 18:06:26 Running on server: post build plugin 'Clover Delta Calculator' simple 12-Aug-2025 18:06:26 Running on server: post build plugin 'Maven Dependencies Postprocessor' simple 12-Aug-2025 18:06:26 All post build plugins have finished simple 12-Aug-2025 18:06:26 Generating build results summary... simple 12-Aug-2025 18:06:26 Saving build results to disk... simple 12-Aug-2025 18:06:26 Store variable context... simple 12-Aug-2025 18:06:26 Indexing build results... simple 12-Aug-2025 18:06:26 Finished building GCPXY3-DOC-JOB1-83.
最新发布
08-14
<think>我们首先需要分析在Docker部署过程中服务不可用的阶段,然后结合日志(特别是Bamboo构建日志和Docker Compose日志)来确定具体的不可用时间段。 ### 服务不可用的阶段回顾 根据之前的讨论,在Docker Compose部署过程中,服务不可用主要发生在以下阶段: 1. **旧容器停止阶段**:当执行`docker-compose stop`或`up`命令中的重建(`--force-recreate`)时,旧容器会先停止(发送SIGTERM信号),此时服务已不可用。 2. **新容器启动阶段**:新容器启动后,直到其通过健康检查(如果有配置)或完全就绪之前,服务仍不可用。这个阶段包括应用初始化(如连接数据库、加载配置等)。 ### 通过日志确定不可用时间段 要确定服务不可用的具体时间段,我们需要从以下日志中获取关键时间戳: #### 1. Bamboo构建日志 在Bamboo构建计划中,通常会执行如下步骤(参考引用[4]): ```bash docker build -t $NAME:$TAG . docker-compose -f $YAML -p $PROJECT_NAME stop docker-compose -f $YAML -p $PROJECT_NAME up -d ``` 关键时间点: - `docker-compose stop`命令执行的时间:此时旧容器停止,服务开始不可用。 - `docker-compose up -d`命令执行的时间:此时开始启动新容器。 #### 2. Docker Compose日志 通过`docker-compose logs`可以获取容器的详细日志。重点关注: - 旧容器的停止时间:在日志中搜索旧容器退出的记录(如`exited with code 0`)。 - 新容器的启动时间:在日志中搜索新容器启动的记录(如`Starting...`)。 - 新容器的就绪时间:在日志中搜索应用启动完成的记录(如应用框架的启动完成消息,或健康检查通过的日志)。 ### 步骤:确定不可用时间段 1. **从Bamboo日志中提取关键命令执行时间**: - 记录`docker-compose stop`命令的开始和结束时间。 - 记录`docker-compose up -d`命令的开始时间。 2. **从Docker Compose日志中提取容器事件时间**: - 使用`docker-compose logs --timestamps ghc-web`获取带时间戳的日志。 - 查找旧容器停止的日志行(例如,应用收到SIGTERM信号并开始关闭)。 - 查找新容器启动的日志行(例如,应用开始启动)。 - 查找新容器就绪的日志行(例如,应用监听端口或通过健康检查)。 3. **计算不可用时间段**: - **不可用开始时间**:旧容器停止命令执行时间(或旧容器实际停止的日志时间)。 - **不可用结束时间**:新容器通过健康检查(或应用就绪)的日志时间。 ### 示例:日志分析 假设Bamboo日志片段: ``` 2024-06-15 10:00:00,000 INFO: Running: docker-compose -f docker-compose-web-prod.yml -p myproject stop 2024-06-15 10:00:05,000 INFO: Running: docker-compose -f docker-compose-web-prod.yml -p myproject up -d ``` Docker Compose日志(旧容器): ``` 2024-06-15T10:00:01.000Z myproject_ghc-web_1 | Received SIGTERM, shutting down... 2024-06-15T10:00:02.000Z myproject_ghc-web_1 | Service stopped. ``` Docker Compose日志(新容器): ``` 2024-06-15T10:00:06.000Z myproject_ghc-web_1 | Starting service... 2024-06-15T10:00:10.000Z myproject_ghc-web_1 | Connected to database. 2024-06-15T10:00:12.000Z myproject_ghc-web_1 | Listening on port 8080. ``` 则不可用时间段为: - **开始**:2024-06-15 10:00:01(旧容器收到SIGTERM) - **结束**:2024-06-15 10:00:12(新容器监听端口,服务就绪) - **总不可用时间**:11秒 ### 优化建议 1. **配置健康检查**:在`docker-compose.yml`中为服务配置健康检查,这样Docker可以自动判断服务何时就绪[^3]。 2. **使用滚动更新**:在Docker Swarm模式下,通过滚动更新策略(`update_config`)实现零停机部署[^4]。 3. **优雅停止**:确保应用正确处理SIGTERM信号,在关闭前完成正在处理的请求。 ```mermaid graph TD A[Bamboo日志] -->|提取时间戳| B(旧容器停止时间) C[Docker日志] -->|旧容器日志| B C -->|新容器日志| D(新容器就绪时间) B --> E[计算不可用时间段] D --> E ``` ### 如何获取日志 1. **Bamboo日志**:在Bamboo构建结果页面查看构建日志。 2. **Docker Compose日志**: ```bash # 获取带时间戳的日志(新容器启动后) docker-compose -f docker-compose-web-prod.yml logs --timestamps --tail=100 ghc-web ``` 注意:如果旧容器日志已被覆盖,可以配置Docker日志驱动(如`json-file`)并设置更大的日志大小限制。 ### 相关问题 1. 如何配置Docker Compose健康检查以减少服务中断时间? 2. 在Docker部署中,如何确保旧容器优雅关闭? 3. 如何从Docker日志中提取关键事件的时间戳? 4. 在Bamboo中如何优化构建计划以实现更快的部署? 通过以上步骤,你可以精确分析出服务在Docker部署过程中的不可用时间段,并针对性地进行优化。</think>### 分析 Docker 部署时服务不可用的阶段及日志定位 根据 Docker 部署流程和引用内容,服务不可用主要发生在以下阶段,通过分析日志可精确确定不可用时间段: --- #### 一、服务不可用的关键阶段分析 1. **容器重建过渡期(核心中断阶段)** - **旧容器停止 → 新容器就绪** 的时间窗口(参考 `--force-recreate` 行为[^1]) - **中断触发点**: - 旧容器收到 `SIGTERM` 信号(服务停止响应) - 新容器启动但未通过健康检查(若有配置) - **持续时间公式**: $$T_{down} = T_{stop\_old} + T_{start\_new} + T_{healthcheck}$$ - $T_{stop\_old}$:旧容器优雅关闭时间(默认 10s) - $T_{start\_new}$:新容器启动初始化时间(依赖应用) - $T_{healthcheck}$:健康检查重试时间(若配置) 2. **镜像构建阶段(潜在风险)** - `docker build` 期间旧容器仍运行(服务正常)[^4] - **风险场景**:构建失败且旧容器已被移除(如前置 `stop` 命令) --- #### 二、通过日志定位不可用时间段 结合 `docker-compose` 和 Bamboo 日志分析流程: ```mermaid graph LR A[Bamboo日志] -->|1.提取时间戳| B[构建命令时间点] C[Docker日志] -->|2.分析容器事件| D[停止/启动时间] D -->|3.计算差值| E[不可用时间段] ``` ##### 具体步骤: 1. **从 Bamboo 日志提取关键时间点**(参考引用[4]): ```bash # 示例日志片段 2023-10-01 12:00:00 INFO: docker-compose stop # T1: 停止旧容器 2023-10-01 12:00:05 INFO: docker-compose up -d # T2: 启动新容器 ``` 2. **从 Docker 日志获取容器状态变化**: ```bash docker logs --since $T1 --until $T2 <container_id> ``` - **关键日志标记**: ``` # 旧容器停止 2023-10-01T12:00:01Z Received SIGTERM, shutting down... 2023-10-01T12:00:03Z Container exited # 新容器启动 2023-10-01T12:00:06Z Starting application... 2023-10-01T12:00:15Z Health check passed # T3: 服务就绪 ``` 3. **计算不可用时间段**: - **服务中断开始**:`T1 + 旧容器优雅关闭时间`(如 `12:00:01`) - **服务恢复结束**:`T3`(如 `12:00:15`) - **总不可用时间**:`14秒` --- #### 三、优化建议(减少不可用时间) 1. **配置健康检查**(缩短 $T_{healthcheck}$)[^3]: ```yaml services: ghc-web: healthcheck: test: curl -f http://localhost:8080/health || exit 1 interval: 3s timeout: 2s retries: 3 # 最大等待 9s ``` 2. **实现零停机部署**: - 使用 `docker-compose up --no-deps --scale ghc-web=2` 先启动新容器 - 通过负载均衡切换流量后再停旧容器 3. **日志分析工具**: ```bash # 提取关键事件时间戳 docker events --filter 'event=die' --filter 'container=<old_container_id>' docker events --filter 'event=health_status: healthy' --filter 'container=<new_container_id>' ``` --- #### 四、相关实践问题 1. 如何通过 Bamboo 日志识别因镜像构建失败导致的服务中断? - 检查 `docker build` 退出码(非 0 即失败)[^4] - 分析构建失败后是否执行了 `docker-compose stop` 2. 如何区分服务不可用是源于容器启动失败还是健康检查超时? - 启动失败:Docker 日志包含 `Container failed to start` - 健康检查超时:日志包含 `Unhealthy` 但容器仍在运行 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值