1. 把代码从github等托管服务器上更新下来 2. 编译成war文件 3. 重启tomcat 第一次使用时，先手动地把代码拉到一个固定的目录中 cd /home/me/myappsite/code git clone https://someuser@somesite/myapp.git 一键脚本：build-my.sh #!/bin/sh echo “pull and build” cd /home/me/myappsite/code/myapp git pull mvn clean mvn package -DskipTests echo “shutting down the tomcat” kill $(ps aux | grep ‘java’ | grep ‘mytomcat’| awk ‘{print $2}’) #不要用shutdown.sh；这里需要同步杀死进程，shutdown.sh做不到同步杀 echo “clean existing war files and copy the new one” …
典型的java网站： 用centos做操作系统，用tomcat提供服务，用apache httpd做反向代理 apache httpd配置 引用 #一个IP多个域名 NameVirtualHost *:80 #禁止直接使用ip访问 <VirtualHost *:80> ServerName 11.11.11.11 <Location /> Order deny,allow Deny from all </Location> </VirtualHost> #顶级域名跳转到www域名 <VirtualHost *:80> ServerName my.com RewriteEngine on RewriteCond %{http_host} ^my.com [NC] RewriteRule ^(.*)$ http://www.my.com/$1 [L,R=301] </VirtualHost> #把对apache的访问指向tomcat <VirtualHost *:80> ServerName www.my.com …
在aws ec2中搭建apache httpd或tomcat后，发现使用ec2 instance的public ip在浏览器里访问相关服务时失败。 这是因为防火墙未设置。对ec2来说，security group就相当于防火墙。 设置办法： 进入instance列表，在security group列中找到对应的group, 点击它，然后Actions => Edit Inbound Rules, 加入http, 即可允许80端口访问。 如果要打开8080的http端口，新增一个custom tcp rule.
在innodb的binlog文件中，如果一个事务从第m行开始，在第n行结束；那么从m到n之间只会记录本事务的操作，不会记录其他事务的行为。 这是因为innodb中binary log entries总是以事务为单位整体写入文件的。 引用 Within an uncommitted transaction, all updates (UPDATE, DELETE, or INSERT) that change transactional tables such as BDB or InnoDB tables are cached until a COMMIT statement is received by the server. At that point, mysqld writes the entire transaction to the binary log before the COMMIT is executed. 推论： 1. …
mysqldump默认情况下并不保证数据一致性。 在innodb中，可以这样： mysqldump –single-transaction mydb > mydb-backup.sql 如果有 –single-transaction参数，mysqldump会将整个数据的读取过程置于一个满足repeatable read的事务中，最后导出的数据也是相互一致的。 由于innodb的mvcc特性，使用 –single-transaction执行mysqldump, 不会阻塞其他进程的读写。
Logical Backup 就是用诸如mysqldump这样的工具把数据导出为可视的sql文件或csv文件。 Raw Backup 则是指直接备份数据库的数据文件。 Raw Backup执行起来比Logical Backup快的多，因为它不需要消耗CPU/内存把数据变成sql或csv(顺便说一下，变csv比变sql要快很多）。 但Raw Backup有一个缺点：Raw File的跨平台能力比较弱。 一个windows下的文件在linux下可能就用不了，一个从mysql 5.1导出的文件可能无法被mysql 5.5识别。 Raw Backup还有一个严重的缺点： 如果Raw File是一个Corrupted File, 复制后产生的备份仍是一个Corrupted File; 这个备份就没有作用，因为你没法利用它来恢复数据。
数据备份对数据库本身有cpu压力；如果为了追求一致性，可能还要施加锁表操作，影响一定的可用性。数据量越大，这些代价就越高。 可以专门设置一个备库，然后从这个备库中把数据和binlog备份出来。
mysql, 不管用的是不是innodb, 都有binlog. 这个binary log跟transaction没关系，它主要用于replication和backup. log文件会一直递增，不会循环使用(后面的记录不会覆盖前面的） 同时，innodb还有redo log/undo log. 它们用于transaction, 且会循环使用。
默认情况下，一个写操作就是一次事务。 如果一次业务操作包含三次DB写操作，三个写操作就是三个事务，三个事务导致三次log flush(磁盘读写，代价较高）： 引用 InnoDB must flush the log to disk at each transaction commit if that transaction made modifications to the database. 所以应该把这三次DB写操作合在一个事务里，这样只需要做一次flush disk。
摘自High Performance MySQL 复制过程的核心是binlog 拓扑方面： 1. 一主一备最常见，可满足典型的读写分离需求 2. 一主多备也可以，但要注意备机太多可能导致主机负担过大。有个办法是主机只挂一个特殊的备机，其他备机再从这个特殊备机中同步数据（即把特殊备机当作主机），把主机的同步负担转移到特殊备机上。这个策略叫distribution master 3. 你可能会想用主主双活(Master-Master in Active-Active Mode)来同时分担读负担和写负担，即两台机分别是对方的备机，每台机都可以读和写，并互相数据同步。但这样做在数据一致性方面的问题非常多，严重不推荐。比如说，数据同步失效了，但两台机仍在提供写服务，怎么办？数据肯定不一致了。 4. 比较受推荐的模式是主主轮活(Master-Master in Active-Passive Mode)，即在某一时刻总是一主一备，但必要时可以立即互换主备角色。这种模式在可用性方面（即无当机时间）很有帮助。比如，alter table可能会比较久，造成数据库不可用；但在主主轮活模式下，可以先去备机alter table, 然后切换一下角色，让原备机变成新主机提供服务，让原主机以新备机的角色同步alter table行为。这个过程中不会有down time.