由于某些历史问题，最近终于可以从java中解脱出来，继续耕耘.Net了，第一步就是把之前的java项目翻成.net。之前已经实现过一次，翻起来还是比较快的(当然基础架构/实体模型已经重新思考并改进)，而且测试也在跟进，所以一天要发无数次版本，还要考虑开发环境、测试环境，总发布出错，甚是心累。于是下决心改善效率，以上为背景。 看了很多文章，最终决定使用Jenkins。以下是我整个配置的记录： 1. 环境 Platform: .Net4.5 IDE: Visual Studio 2015 & MsBuild 包管理:NuGet 版本控制:TFS-git 服务器: windows 2012 R2(IIS8) 其他: webdeploy […]
1、Jenkins是什么? Jenkins是一个可扩展的持续集成的引擎，主要用于持续自动的构建、测试软件项目 监控一些定时执行的任务。 2、安装配置 最新的Jenkins 安装包可以从这里下载：http://jenkins-ci.org/ 下载完成后点击 setup.exe 然后入Next 安装完成后我们可以看到在windows服务中多了一个叫Jenkins的服务 我们还可以得到一个网站 http://localhost:8080/ ，打开这个网站，我们可以看到我们的Jenkins已经安装好了。 首先，我们点击系统管理，管理插件 更新svn插件 因为我们是编译.NET程序，所以我们需要另外一个叫MSBuild的插件，我们到可选插件，搜索MSBuild，下载安装，如下图 都安装完毕以后，点击系统管理，系统设置 我们到系统设置界面找到MSBuild 其中
最近好久没有更新文章了，因为好久没有写代码了，以至于我不知道同大家分享些什么，刚好，今天突然叫我学习下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， 然后填写信息。
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使用的内存最大的尺寸
前言 mysql数据库做主从复制，不仅可以为数据库的数据做实时备份，保证数据的完整性，还能做为读写分离，提升数据库的整体性能。但是，mysql主从复制经常会因为某些原因使主从数据同步出现异常。因此，下面介绍的是mysql主从同步异常的原因及恢复的方法。 auto.cnf 配置问题 这个问题是在部署主从复制的时候，可能会遇到的 【1】报错 Last_IO_Error: Fatal error: The slave I/O thread stops because master and slave have equal
MySQL数据库自身提供的主从复制功能可以方便的实现数据的多处自动备份，实现数据库的拓展。多个数据备份不仅可以加强数据的安全性，通过实现读写分离还能进一步提升数据库的负载性能。 下图就描述了一个多个数据库间主从复制与读写分离的模型(来源网络)： 在一主多从的数据库体系中，多个从服务器采用异步的方式更新主数据库的变化，业务服务器在执行写或者相关修改数据库的操作是在主服务器上进行的，读操作则是在各从服务器上进行。如果配置了多个从服务器或者多个主服务器又涉及到相应的负载均衡问题，关于负载均衡具体的技术细节还没有研究过，今天就先简单的实现一主一从的主从复制功能。 Mysql主从复制的实现原理图大致如下(来源网络)： MySQL之间数据复制的基础是二进制日志文件（binary log file）。一台MySQL数据库一旦启用二进制日志后，其作为master，它的数据库中所有操作都会以“事件”的方式记录在二进制日志中，其他数据库作为slave通过一个I/O线程与主服务器保持通信，并监控master的二进制日志文件的变化，如果发现master二进制日志文件发生变化，则会把变化复制到自己的中继日志中，然后slave的一个SQL线程会把相关的“事件”执行到自己的数据库中，以此实现从数据库和主数据库的一致性，也就实现了主从复制。 实现MySQL主从复制需要进行的配置： 主服务器： 开启二进制日志 配置唯一的server-id 获得master二进制日志文件名及位置 创建一个用于slave和master通信的用户账号 从服务器： 配置唯一的server-id 使用master分配的用户账号读取master二进制日志 启用slave服务 具体实现过程如下： 一、准备工作： 1.主从数据库版本最好一致
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
在网上搜索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
tomcat 日志说明 配置文件server.xml 默认日志格式为 pattern=”%h %l %u %t "%r" %s %b” 推荐使用 pattern=”%{X-FORWARDED-FOR}i %l %u %t %r %s %b %D
问题症状 RDS数据库经常收到CPU使用率高的监控报警，找不到具体的原因，只能重启RDS实例来解决。 问题原因 要彻底解决监控报警问题，需要找到问题的根源，CPU使用率高的原因，一般情况下导致CPU使用率有以下几个原因： 系统执行应用提交查询（包括数据修改操作）时需要大量的逻辑读 实例的 QPS（每秒执行的查询次数）高 查询执行成本（查询访问表数据行数 avg_lgc_io）高 解决方案 生成诊断报告，查看诊断报告提供的优化建议进行SQL优化 对于由应用负载高导致的 CPU 使用率高的状况，使用 SQL 查询进行优化的余地不大，建议从应用架构、实例规格等方面来解决，例如： 升级实例规格，增加 CPU 资源。 增加只读实例，将对数据一致性不敏感的查询（比如商品种类查询、列车车次查询）转移到只读实例上，分担主实例压力。