今天看到个Wordpress的插件BackWPup，据说是备份wp的好帮手。突然想起自己博客上次备份已经不知道是什么时候了，觉得有点对不住它，就想用这个工具试一下。
在备份前我就想知道如何在将来用备份的文件进行恢复，于是就在BackWPup选项中找到了restore，当时眼一花，手一滑，点了restore，在那十分之一秒内想，总不会这样就直接恢复了吧？怎么也应该有个确认提示吧？结果直接看到“恢复成功，现在可以删掉备份的xxx文件”，擦。。。回首页一看，10年5月，time machine！。。。
原来wp的根目录下竟然有10年5月的一个mysql备份文件；BackWPup竟然就需要这么一个文件在这么一个地点；BackWPup恢复时竟然就没有确认选项。。。
最后用胡辣汤期货为诱饵，让鲶总找到了今年3月他不经意的一次mysql备份，恢复；又用BlogSync和live writer从另一个平行世界同步回了剩下的帖子。赶快在BackWPup设置了一个任务：每天夜里3点自动把博客统统打包，发送到dropbox里去。。。
2012年9月2日星期日
2012年8月16日星期四
利用Nginx做反向代理搭建ArcGIS 10.1 for Server集群环境
搭建GIS Server集群环境时，通常不建议在GIS Server之间设置防火墙；而建议在服务器环境的前端设置反向代理来隐藏服务器环境的真实地址及端口，保险起见可将反向代理放入DMZ区（前后都设置防火墙），增加安全性。
ArcGIS 10.1 for Server做出的架构改进使得我们在搭建GIS服务器集群环境时更加容易和省心；Nginx因其高性能，耗资源少，稳定性高，成本低廉，配置简单等诸多特性被越来越多地使用。这里简单介绍如何利用Nginx做反向代理并实现Web层的负载均衡效果，来搭建ArcGIS 10.1 for Server集群环境的过程。具体环境如下：
由于是Windows环境，从官网上下载稳定的1.2.3版本，解压到192.168.0.69机器的c:\nginx-1.2.3目录下。因为我们打算让Nginx监听80端口，所以需要将本身占用80端口的IIS默认网站停掉。打开conf目录下的nginx.conf文件，修改如下：
命令行方式输入'start nginx'启动Nginx，然后发送请求到192.168.0.69机器的80端口：
看到请求被转发到了247机器的IIS 7.5上，再次刷新，
请求已经轮询到了244机器的IIS 6.0上。最后通过69机器来访问ArcGIS Server的Services Directory，
此时Nginx会以轮询的方式访问247和244两台机器的Web Adaptor。
这里只是针对ArcGIS for Server集群环境配置做了简单介绍，在实际中可能还需考虑搭建可容错的共享存储环境，DNS服务器的配置，硬件防火墙的配置，Nginx具体参数的配置等因素。
ArcGIS 10.1 for Server做出的架构改进使得我们在搭建GIS服务器集群环境时更加容易和省心；Nginx因其高性能，耗资源少，稳定性高，成本低廉，配置简单等诸多特性被越来越多地使用。这里简单介绍如何利用Nginx做反向代理并实现Web层的负载均衡效果，来搭建ArcGIS 10.1 for Server集群环境的过程。具体环境如下：
- 192.168.0.247（Windows Server 2008 R2）：安装Web Server（IIS 7.5），Web Adaptor（使用默认80端口），ArcGIS 10.1 for Server（使用默认6080端口）；
- 192.168.0.244（Windows Server 2003 R2）：安装Web Server（IIS 6.0），Web Adaptor（使用默认80端口），ArcGIS 10.1 for Server（使用默认6080端口）；
- 192.168.0.69（Windows 7）：运行Nginx，监听本地80端口；
由于是Windows环境，从官网上下载稳定的1.2.3版本，解压到192.168.0.69机器的c:\nginx-1.2.3目录下。因为我们打算让Nginx监听80端口，所以需要将本身占用80端口的IIS默认网站停掉。打开conf目录下的nginx.conf文件，修改如下：
命令行方式输入'start nginx'启动Nginx，然后发送请求到192.168.0.69机器的80端口： 
看到请求被转发到了247机器的IIS 7.5上，再次刷新， 
请求已经轮询到了244机器的IIS 6.0上。最后通过69机器来访问ArcGIS Server的Services Directory， 
此时Nginx会以轮询的方式访问247和244两台机器的Web Adaptor。 这里只是针对ArcGIS for Server集群环境配置做了简单介绍，在实际中可能还需考虑搭建可容错的共享存储环境，DNS服务器的配置，硬件防火墙的配置，Nginx具体参数的配置等因素。
2012年8月14日星期二
ArcGIS 10.1 for Server机器判断本机是否已经加入site的依据
在一台机器上安装ArcGIS 10.1 for Server后，它还无法立即工作，必须将其加入site（的cluster）之中才行。首次登录manager时，也会询问创建新的site还是加入已有的site；如果已经加入site，登录manager则会显示该site的管理目录。那么机器自身是如何判断出自己是否已经加入site了呢？
依据就在于Program Files\ArcGIS\Server\framework\etc目录下的两个xml文件，config-store-connection.xml和machine-config.xml。加入site时会在本机创建这两个文件，退出site时会删除之。前者记录site的公用信息，后者记录本机在site中的信息，具体内容大家可以自己查看。
登录manager时会读取这两个文件，如果找不到，则认为自己没有加入site，会询问创建新site还是加入已有site；如果有这两个文件，会首先访问site的config-store目录验证其内容，合法的情况下就打开site管理目录。 如果在一台机器关机时，从site中将其删除，开机后会根据config-store-connection.xml内容去site的config-store目录中验证，发现自己已经被从site中移除后，会自己删除本机的这两个xml文件。
此外，如果你的机器已经加入了site A，但现在需要临时加入site B去做一些工作，就不用在admin api去删除site A了，只需将上述两个xml文件先转移到别的地方，然后登录manager，选择加入site B即可；之前site A的config-store内容可以保留，以便将先前挪走的两个xml文件复原后（需要重启ArcGIS Server服务），登录manager即可直接返回site A。
依据就在于Program Files\ArcGIS\Server\framework\etc目录下的两个xml文件，config-store-connection.xml和machine-config.xml。加入site时会在本机创建这两个文件，退出site时会删除之。前者记录site的公用信息，后者记录本机在site中的信息，具体内容大家可以自己查看。
登录manager时会读取这两个文件，如果找不到，则认为自己没有加入site，会询问创建新site还是加入已有site；如果有这两个文件，会首先访问site的config-store目录验证其内容，合法的情况下就打开site管理目录。 如果在一台机器关机时，从site中将其删除，开机后会根据config-store-connection.xml内容去site的config-store目录中验证，发现自己已经被从site中移除后，会自己删除本机的这两个xml文件。
此外，如果你的机器已经加入了site A，但现在需要临时加入site B去做一些工作，就不用在admin api去删除site A了，只需将上述两个xml文件先转移到别的地方，然后登录manager，选择加入site B即可；之前site A的config-store内容可以保留，以便将先前挪走的两个xml文件复原后（需要重启ArcGIS Server服务），登录manager即可直接返回site A。
2012年8月10日星期五
ArcGIS 10.1 for Server中Web Adaptor的工作原理
ArcGIS 10.1 for Server的安装目录中，都会内置一个tomcat（Program Files\ArcGIS\Server\framework\runtime\tomcat\），无需单独的Web Server即可发布各种GIS服务（对于熟悉.NET的朋友来说，更省去单独安装和配置IIS的步骤）；AGS应用程序的端口号也由之前版本的80（ArcGIS Server for .NET）和8099/8399（ArcGIS Server for Java）统一到了6080上，比如http://localhost:6080/arcgis/rest/services和http://localhost:6080/arcgis/manager等。但对于内置的这个tomcat，我们并不能进行过多的操作，如果需要部署Web应用或通过别的端口来访问ArcGIS for Server的服务，这时就需要用到新的组件：Web Adaptor了。
Web Adaptor实际上是安装在Web Server机器上的一个Web应用程序，负责将Web Server接收到的GIS请求转发到ArcGIS Server site内的GIS Server机器上去。通过Adaptor这个桥梁，我们就能使ArcGIS for Server利用到企业级Web Server的诸多优势。根据安装帮助中的解释，安装Web Adaptor后主要有以下好处：
以IIS中的Web Adaptor为例（经过Java高手验证WebLogic和WebSphere的Adaptor工作过程与此是完全一致的），看看反编译后的代码。通过查看inetpub\wwwroot\arcgis\Web.config文件得知，IIS中的Web Adaptor主要的工作过程都集中在ESRI.ArcGIS.WebAdaptor.dll（在GAC目录中）里。这个dll里首先找到两个类：
一个Node就对应一个GIS Server机器，_healthy标记该机器的可用状态；NodeManager是所有Node的管理类。Web Adaptor启动时，会调用WebAdaptorConfig.GetMachines()方法，此方法会向http://siteip:port/arcgis/admin/machines发送get请求，获取site内所有GIS Server机器的列表，然后利用UpdateNodeList方法保存在NodeManager类中，并写入WebAdaptor.config文件。
此外，最重要的是一个叫AGSHandler的类，它实现了IHttpHandler接口：
发送到Web Server的GIS请求都会由其中的ProcessRequest方法进行处理。前面说过Web Adaptor是以轮询方式转发请求的，而_currentNodeIndex便记录了请求转发目标GIS Server的在Nodes列表中的索引：
Web Adaptor接收到发到Web Server的GIS请求后，首先会读取初始化时保存的WebAdaptor.config配置文件并查看里面存储的GIS Server机器列表，如果读取失败或者机器个数为0，都会响应500的错误。如1所示；接下来会利用try里的TransferRequest方法将请求转发到具体的GIS Server（的tomcat）上去，如果转发的这个机器没有响应，则会在catch中将此机器利用MarkUnHealthy方法标记为不可用；而不论当前节点是否成功接收请求，TransferRequest方法中都会将_currentNodeIndex节点加一，保证下一个请求发送到下一台GIS Server上去，以实现轮询请求的事实：
最后来看看Web Adaptor是如何根据配置文件的间隔时间去追询标记为下线机器的状态，在机器上线后又将它们加回可用机器列表的：
可以看出，Web Adaptor检测到没有响应的机器后，除了标记其为不可用，也会同时启动一个定时器，此定时器逝去配置文件中的检测下线机器状态时间间隔（分钟）后，会立即将这台机器重新标记为可用，而不会去检测它事实上是否可用。判断机器是否真正可用的过程还是通过前面TransferRequest方法来完成的，即直接向其转发请求，如正常响应，证明其已经在线；如不能正常响应，则再次标记其不可用，重新启动定时器进入下一个轮回…
大家可以想一想，整个过程是否有不合理的地方呢？
Web Adaptor实际上是安装在Web Server机器上的一个Web应用程序，负责将Web Server接收到的GIS请求转发到ArcGIS Server site内的GIS Server机器上去。通过Adaptor这个桥梁，我们就能使ArcGIS for Server利用到企业级Web Server的诸多优势。根据安装帮助中的解释，安装Web Adaptor后主要有以下好处：
- 将单独的企业级Web Server集成到ArcGIS for Server的部署架构中来。可以将利用ArcGIS for Server服务的Web应用部署到Web Server上去；可以为site内所有的GIS Server提供不含有6080端口及arcgis等字样的统一访问入口点；
- 可阻止最终用户通过Web Adaptor的访问地址连接到ArcGIS for Server的相关管理程序。比如用户如果得知了类似6080端口的GIS服务访问地址，就可通过固定的url地址访问到Manger，Admin api等涉及到整个站点操作的内置应用。而Web Adaptor给我们提供了选项，可禁止用户通过Web Adaptor暴露出的GIS服务地址访问到这些管理应用。
以IIS中的Web Adaptor为例（经过Java高手验证WebLogic和WebSphere的Adaptor工作过程与此是完全一致的），看看反编译后的代码。通过查看inetpub\wwwroot\arcgis\Web.config文件得知，IIS中的Web Adaptor主要的工作过程都集中在ESRI.ArcGIS.WebAdaptor.dll（在GAC目录中）里。这个dll里首先找到两个类：
一个Node就对应一个GIS Server机器，_healthy标记该机器的可用状态；NodeManager是所有Node的管理类。Web Adaptor启动时，会调用WebAdaptorConfig.GetMachines()方法，此方法会向http://siteip:port/arcgis/admin/machines发送get请求，获取site内所有GIS Server机器的列表，然后利用UpdateNodeList方法保存在NodeManager类中，并写入WebAdaptor.config文件。 此外，最重要的是一个叫AGSHandler的类，它实现了IHttpHandler接口：
发送到Web Server的GIS请求都会由其中的ProcessRequest方法进行处理。前面说过Web Adaptor是以轮询方式转发请求的，而_currentNodeIndex便记录了请求转发目标GIS Server的在Nodes列表中的索引： 
Web Adaptor接收到发到Web Server的GIS请求后，首先会读取初始化时保存的WebAdaptor.config配置文件并查看里面存储的GIS Server机器列表，如果读取失败或者机器个数为0，都会响应500的错误。如1所示；接下来会利用try里的TransferRequest方法将请求转发到具体的GIS Server（的tomcat）上去，如果转发的这个机器没有响应，则会在catch中将此机器利用MarkUnHealthy方法标记为不可用；而不论当前节点是否成功接收请求，TransferRequest方法中都会将_currentNodeIndex节点加一，保证下一个请求发送到下一台GIS Server上去，以实现轮询请求的事实： 
最后来看看Web Adaptor是如何根据配置文件的间隔时间去追询标记为下线机器的状态，在机器上线后又将它们加回可用机器列表的： 
可以看出，Web Adaptor检测到没有响应的机器后，除了标记其为不可用，也会同时启动一个定时器，此定时器逝去配置文件中的检测下线机器状态时间间隔（分钟）后，会立即将这台机器重新标记为可用，而不会去检测它事实上是否可用。判断机器是否真正可用的过程还是通过前面TransferRequest方法来完成的，即直接向其转发请求，如正常响应，证明其已经在线；如不能正常响应，则再次标记其不可用，重新启动定时器进入下一个轮回… 大家可以想一想，整个过程是否有不合理的地方呢？
2012年7月5日星期四
ArcSDE 10.1 for PostgreSQL on Windows安装
ArcGIS换了10.1后，需要安装SDE，按照以前的习惯依然选用PostgreSQL。但10.1的SDE安装步骤变化不小，记录下来供有需要的朋友参考。
首先，安装介质上不再自带PostgreSQL数据库的安装文件了，需要自己下载。系统要求上指明支持的版本是9.0.5 64bit（所有Enterprise SDE只支持64位的数据库），我在官网上下载了最接近的9.0.8版本，安装。
其次，10.1版本在弱化ArcSDE服务连接的事实，所有文档默认使用直连的方式。最明显的体现是，将以前的Post Installation的步骤（创建数据库用户，系统表，Schema等工作）从ArcSDE的软件安装步骤中剥离了出来，而能够（也仅能够）采用名为Create Enterprise Geodatabase的新GP工具来完成。因此，如果不需要ArcSDE服务连接方式的话，就无需安装ArcSDE软件了。
下面说明建立直连方式的完整安装步骤（参考此安装文档）：
首先，安装介质上不再自带PostgreSQL数据库的安装文件了，需要自己下载。系统要求上指明支持的版本是9.0.5 64bit（所有Enterprise SDE只支持64位的数据库），我在官网上下载了最接近的9.0.8版本，安装。
其次，10.1版本在弱化ArcSDE服务连接的事实，所有文档默认使用直连的方式。最明显的体现是，将以前的Post Installation的步骤（创建数据库用户，系统表，Schema等工作）从ArcSDE的软件安装步骤中剥离了出来，而能够（也仅能够）采用名为Create Enterprise Geodatabase的新GP工具来完成。因此，如果不需要ArcSDE服务连接方式的话，就无需安装ArcSDE软件了。
下面说明建立直连方式的完整安装步骤（参考此安装文档）：
- 安装PostgreSQL数据库；
- （可选）修改%PostgreSQL%\9.0\data\pg_hba.conf文件，添加“host all all 0.0.0.0/0 md5”记录，让任意客户端均可连接你的数据库集群（修改后需重启postgresql-x64-9.0服务以生效）；
- 从%Program Files%\ArcGIS\Desktop10.1\DatabaseSupport\PostgreSQL\Windows64目录下，拷贝st_geometry.dll文件到%PostgreSQL%\9.0\lib目录。在PostgreSQL中创建Geodatabase时必须用到此类库；
- 配置PostgreSQL的客户端。因为直连方式要求ArcSDE的客户端必须安装数据库的客户端类库，所以首先需要获取PostgreSQL的客户端。ArcGIS Desktop是32位软件，需要的是32位的PostgreSQL类库。我在官网上的zip archive链接中下载了32位的PostgreSQL binary文件，解压后将bin目录中的libeay32.dll, libiconv-2.dll, libintl-8.dll, libpq.dll, and ssleay32.dll文件拷贝到%Program Files%\ArcGIS\Desktop10.1\bin目录下；如果ArcGIS Server也需要直连到PostgreSQL中，则需要拷贝
libeay32.dll, libintl.dll, libpq.dll, and ssleay32.dll上述同名的5个64位的库（帮助中的64位库列表有误）到%Program Files%\ArcGIS\Server\bin目录下，因为ArcGIS Server现在是64位的软件了，这几个库可在PostgreSQL 64位的安装目录下找到； - 在ArcMap中使用Create Enterprise Geodatabase工具完成“Post Installation”过程。
对于PostgreSQL库来说Instance是数据库所在的服务器名称；Database是所要新建的GDB名称；对于PostgreSQL，GDB Administrator只能是sde；如果Tablespace Name留空，会将GDB创建到默认的pg_default表空间里； - 建立直连连接。通过Add Database Connections建立直连连接：
Database是刚才创建的GDB名称。
- 安装ArcSDE for PostgreSQL 10.1；
- 修改%Program Files%\ArcGIS\ArcSDE\pgexe\etc\services.sde文件和Windows\System32\drivers\etc\hosts文件，分别增加“esri_sde 5151/tcp”记录；
- 创建ArcSDE服务。你会发现1中安装完ArcSDE后没有弹出后配置的对话框，也无法从开始菜单中找到它，sdesetup命令也没有了install的操作，这也是前面为什么说这个工作仅能够通过新的GP工具来完成的原因。所以以前后配置向导中创建ArcSDE服务的工作就只能通过命令行方式来完成了，分别键入以下两个命令以完成在注册表中创建服务的工作：
sdeservice -o create -d POSTGRESQL,postgresql-x64-9.0
sdeservice -o register -d POSTGRESQL,postgresql-x64-9.0 -r ADMIN_DATABASE -v sde - 启动服务。可以用“sdemon –o start”命令或从Windows服务面板中启动ArcSDE服务；
- 创建连接。Add Database Connection只能创建直连连接，因此需要使用新的Create ArcSDE Connection File GP工具来创建ArcSDE服务连接文件。为了保持以前版本的使用习惯，可将新创建的.sde文件位置保存在c:\Users\Administrator\AppData\Roaming\ESRI\Desktop10.1\ArcCatalog\目录中，这样就可以从Database Connections节点中方便的找到它了。
订阅：
博文 (Atom)
博文
