Author: Vinny

最近好久没有更新文章了，因为好久没有写代码了，以至于我不知道同大家分享些什么，刚好，今天突然叫我学习下jenkins每日构建，我就把今天的学习笔记记录下来，这其中很多东西都是公司同事之前调研总结的，我在他的基础上进行了更加详细的整理，并自己一步一步的对着实现了一下。 环境准备 下载jenkins的windows版本 http://ftp.yz.yamagata-u.ac.jp/pub/misc/jenkins/windows/jenkins-1.650.zip 当然，你可以从官网 http://jenkins-ci.org/下载最新的Windows安装包。 Microsoft Visual Studio Express 2012 for Web https://www.microsoft.com/zh-cn/download/details.aspx?id=30669 Git https://github.com/git-for-windows/git/releases/download/v2.7.2.windows.1/Git-2.7.2-64-bit.exe 使用步骤 1、安装jenkins、git和vs2012 for web，并确保机器上安装了.net framework 4.5和.net framework4.0 ，完成后访问http://localhost:8080。 2、进入插件管理，安装MSBuild Plugin、Git plugin两个插件。将开发机上的C:\Program Files (x86)\MSBuild文件夹直接拷贝到编译机上。 选中“可选插件”页签，然后在过滤栏输入对应的插件名称，查到所需的插件后，直接点击安装即可。 安装完成之后，在已安装页签里面就能够看到安装了的插件，记得安装完插件之后，要重启一下Jenkins。 CMD——services.msc，重启Jenkins服务 3、进入系统设置添加MSBuild和Git配置，如下图 4、新增一个项目，选择构建一个自由风格的软件项目。 5、配置git信息 6、增加构建步骤，并选择Build a Visual Studio project or solution using MSBuild， 然后填写信息。 MSBuild Build File 是项目文件或者工程文件的名称，简单的说就是需要发布的项目对应的项目文件，这里可以配置成相对路径，把有.git文件目录当成根目录，如MSD_ClearCustomsNew/Uuch.MSD/Uuch.MSD.csproj，注意路径的斜杠是/ Command Line Arguments 是命令行参数 /t:Rebuild 表示每次都重建，不使用增量编译 /property:Configuration=Release 表示编译Release版本， PublishProfile指定创建的Profile名称（没有扩展名)，VS发布项目时的配置文件名称 DeployOnBuild=true 表示启用编译并发布 VisualStudioVersion=11.0 表示VS2012 7、如何发布VS2010的Web站点，如果是发布Web站点，可以直接指定需要发布站点的csproj文件,如 使用如下参数： /t:ResolveReferences;Compile /t:_CopyWebApplication /p:Configuration=Release /p:WebProjectOutputDir=C:\Jenkins_Publish /p:OutputPath=C:\Jenkins_Publish\bin…

binlog二进制日志对于mysql数据库的重要性有多大，在此就不多说了。下面根据本人的日常操作经历，并结合网上参考资料，对binlog日志使用做一梳理： 一、binlog日志介绍 1. 什么是binlog binlog日志用于记录所有更新了数据或者已经潜在更新了数据（例如，没有匹配任何行的一个DELETE）的所有语句。语句以“事件”的形式保存，它描述数据更改。 2. binlog作用 因为有了数据更新的binlog，所以可以用于实时备份，与master/slave主从复制结合。 3. binlog有关参数 log_bin 设置此参数表示启用binlog功能，并指定路径名称 log_bin_index 设置此参数是指定二进制索引文件的路径与名称 binlog_do_db 此参数表示只记录指定数据库的二进制日志 binlog_ignore_db 此参数表示不记录指定的数据库的二进制日志 max_binlog_cache_size 此参数表示binlog使用的内存最大的尺寸 binlog_cache_size 此参数表示binlog使用的内存大小，可以通过状态变量binlog_cache_use和binlog_cache_disk_use来帮助测试。 binlog_cache_use：使用二进制日志缓存的事务数量 binlog_cache_disk_use:使用二进制日志缓存但超过binlog_cache_size值并使用临时文件来保存事务中的语句的事务数量 max_binlog_size Binlog最大值，最大和默认值是1GB，该设置并不能严格控制Binlog的大小，尤其是Binlog比较靠近最大值而又遇到一个比较大事务时，为了保证事务的完整性，不可能做切换日志的动作，只能将该事务的所有SQL都记录进当前日志，直到事务结束 sync_binlog 这个参数直接影响mysql的性能和完整性 sync_binlog=0 当事务提交后，Mysql仅仅是将binlog_cache中的数据写入Binlog文件，但不执行fsync之类的磁盘…

前言 mysql数据库做主从复制，不仅可以为数据库的数据做实时备份，保证数据的完整性，还能做为读写分离，提升数据库的整体性能。但是，mysql主从复制经常会因为某些原因使主从数据同步出现异常。因此，下面介绍的是mysql主从同步异常的原因及恢复的方法。 auto.cnf 配置问题 这个问题是在部署主从复制的时候，可能会遇到的 【1】报错 Last_IO_Error: Fatal error: The slave I/O thread stops because master and slave have equal MySQL server UUIDs; these UUIDs must be different for replication…

MySQL 版本 5.6.14 公司有几台MySQL服务器的错误日志显示,有几个系统表不存在. innodb_table_stats innodb_index_stats slave_master_info slave_relay_log_info slave_worker_info 这是因为数据库初始化的时候,dba可能删除过ibdata1文件 虽然重启之后,数据库会自动创建一个ibdata1文件,但是上述系统表也是innodb引擎,所以不能访问了. 这虽然不会影响业务,但是使用innobackupex备份的时候,会写入错误日志. 最后错误日志里,都是这种信息.影响日常检查。 解决的方法. 1.删除上述系统表 drop table mysql.innodb_index_stats; drop table mysql.innodb_table_stats; drop table mysql.slave_master_info; drop table mysql.slave_relay_log_info; drop table mysql.slave_worker_info;…

在网上搜索404配置，有很多配置文章，但都是关于fastcgi_intercept_errors的，不过对我们的项目不起作用。我们的项目使用nginx做反向代理，通过域名区分不同的网站，配置fastcgi_intercept_errors不生效，需要配置proxy_intercept_errors。以下罗列出两种配置方式，供大家参考。 1、fastcgi_intercept_errors 配置方式 （1）创建自己的404.html页面 （2）更改nginx.conf在http定义区域加入： fastcgi_intercept_errors on; （3）更改nginx.conf（或单独网站配置文件，例如在nginx -> sites-enabled下的站点配置文件 ） 中在server 区域加入： error_page 404 = /404.html 或者 error_page 404 = http://www.xxx.com/404.html （4）更改后重启nginx,，测试nginx.conf正确性： /opt/nginx/sbin/nginx –t #502 等错误可以用同样的方法来配置。 error_page 500 502 503…

tomcat 日志说明 配置文件server.xml 默认日志格式为 pattern="%h %l %u %t "%r" %s %b" 推荐使用 pattern="%{X-FORWARDED-FOR}i %l %u %t %r %s %b %D %{User-Agent}i" 日志输出如下 192.168.3.14 - - [14/Dec/2017:17:56:05 +0800] GET /solr/admin/cores?_=1513245362283&indexInfo=false&wt=json HTTP/1.1…

问题症状 RDS数据库经常收到CPU使用率高的监控报警，找不到具体的原因，只能重启RDS实例来解决。 问题原因 要彻底解决监控报警问题，需要找到问题的根源，CPU使用率高的原因，一般情况下导致CPU使用率有以下几个原因： 系统执行应用提交查询（包括数据修改操作）时需要大量的逻辑读 实例的 QPS（每秒执行的查询次数）高 查询执行成本（查询访问表数据行数 avg_lgc_io）高 解决方案 生成诊断报告，查看诊断报告提供的优化建议进行SQL优化 对于由应用负载高导致的 CPU 使用率高的状况，使用 SQL 查询进行优化的余地不大，建议从应用架构、实例规格等方面来解决，例如： 升级实例规格，增加 CPU 资源。 增加只读实例，将对数据一致性不敏感的查询（比如商品种类查询、列车车次查询）转移到只读实例上，分担主实例压力。 使用阿里云 DRDS 产品，自动进行分库分表，将查询压力分担到多个 RDS 实例上。 使用阿里云 Memcache 或者云 Redis 产品，尽量从缓存中获取常用的查询结果，减轻…

最近管理的nginx发现大量的error log，log内容如下： an upstream response is buffered to a temporary file /var/cache/nginx/proxy_temp/0/52/0002923520 while reading upstream 从这条error日志来看是nginx某一块的buffer设置的太小，而response（包含response header和response body）导致response结果不得不临时写到文件中。 可以修改的配置参数 client_header_buffer_size 128k; client_body_buffer_size 1m; proxy_buffer_size 32k; proxy_buffers 64 32k; proxy_busy_buffers_size 1m;…

server { listen 80; server_name jenkins.domainname; return 301 https://$host$request_uri; } server { listen 443 ssl; server_name jenkins.domainname; ssl_certificate /etc/nginx/keypath/jenkins.crt; ssl_certificate_key /etc/nginx/keypath/jenkins.key; location / { proxy_pass http://127.0.0.1:8080; proxy_read_timeout 90; proxy_set_header X-Forwarded-Host…