이 시점에서 WebLogic 10.3.6 는 아주 오래된 버전이다. JDK 1.6 을 기반으로 하고 JEE 도 오래된 버전을 지원한다. 그런데도 간혹 프로젝트를 하다보면 이 버전을 사용하는 곳도 심심치 않아 경악할 때가 있다.
WebLogic 을 버전 업그레이드를 한다고 하려면 어짜피 오래된 버전에 관해서 조금 알아 둘 필요가 있고 WebLogic 의 기본 구성의 경우에는 버전에 크게 상관이 없는 경우도 있어 나름대로 의미가 있다.
설치
WebLogic 10.3.6 버전은 Oracle 홈페이지에서 다운로드 받을 수 있다.정확하게 말하면 WebLogic 10.3.6 버전중에 “Zip distribution with Oracle WebLogic Server only and intended for WebLogic Server” 에 대한 것이다.
위와 같이 파일을 다운로드 받습니다. 그리고 다음과 같이 압축을 해제해 줍니다.
WebLogic 10.3.6 Develop Only
ZSH
1
2
3
]# unzip -o wls1036_dev.zip -d /opt
]# cd /opt
]# ln -s Weblogic10.3.6_dev WLS
그리고 다음과 같이 MW_HOME 환경변수를 세팅해줍니다.
MW_HOME 환경변수 세팅.
ZSH
1
]# export MW_HOME=/opt/WLS
그리고 다음과 같이 configure.sh 파일을 Bash 쉘에 문법에 맞게 고쳐줍니다.
Configure.sh 수정
diff
1
2
3
4
- 14 if [[ -z "$MW_HOME" || ! -d $MW_HOME || ! "$(ls -A $MW_HOME)" ]]; then
+ 14 if [ -z "$MW_HOME" ] || [ ! -d $MW_HOME ] || [ ! "$(ls -A $MW_HOME)" ]; then
- 22 if [[ -z $JAVA_HOME ]] || [[ ! -d "${JAVA_HOME}/bin" ]]; then
+ 22 if [ -z $JAVA_HOME ] || [ ! -d "${JAVA_HOME}/bin" ]; then
Apache Tomcat 도 JNDI 설정을 할 수 있다. 특히나 데이터베이스 연결을 위해서 JNDI 설정을 사용할 수 있다. JNDI 를 사용하면 Web Application 내에서 데이터베이스 연결을 할 필요가 없이 네이밍(Naming) 을 호출함으로써 간단히 해결된다.
이 문서에서는 MySQL 을 위한 Apache Tomcat JNDI 설정 에 대한 것이다.
MySQL Connector/J 설치
JNDI 를 이용해서 MySQL 연결을 설정하기 위해서는 MySQL Connector/J 를 먼저 설치해줘야 한다. 이것은 MySQL 홈페이지에서 다운로드 가능한데 파일이 jar 확장자를 가진 하나의 파일이 필요하다. 이 파일을 Apache Tomcat 라이브러리 디렉토리에 복사해주면 끝난다.
MySQL Connector/J 를 설치했다면, 이제 Apache Tomcat JDNDI 설정을 해야 한다. 이는 Apache Tomcat 의 conf 디렉토리에 context.xml 파일을 다음과 같이 설정 한다. 이 설정을 위해서는 MySQL 연결 정보를 알고 있어야 한다.
Streaming log replication 은 Postgresql 9.0 부터 도입된 기능이다. 이 기능은 Primary 에서 Standby 서버로 직접 전송함으로서 replication delay 를 줄여준다. 따라서 pg_xlog 파일전송이 필요가 없다. 또 xlog 를 Streaming 으로 받기 위해서 Primary 서버에 REPLICATION 권한의 접속 계정이 필요하다.
MySQL 은 인기있는 오픈소스 데이터베이스 시스템이다. 언제나 데이터베이스 시스템이라면 항상 따라오는 것이 Master-Slave 리플리케이션 환경이고 거기에 덧붙여 자동 페일오버(Auto FailOver) 를 어떻게 할 것이라는 골머리 앓는 주제가 따라서 나온다.
MySQL 의 경우에 자체 적인 FailOver 솔루션이 있다. Fabric 이 그것인데, 아직은 많이 쓰이지는 않는 모양이다. 대신에 AutoFailOver 를 지원하는 제3의 툴들이 존재하는데 M-HA 가 바로 이러한 솔루션이다.
M-HA 는 일본인이 Perl 을 이용해서 작성한 솔루션이다. github 저장소에 소스코드는 공개되어 있으며 저장소이름은 mha4mysql-manager 이다.
구조
M-HA 는 Manager 와 Node 로 이루어진다. Node 는 MySQL 이 설치된 서버에 모두 설치해줘야 한다. Mater/Slave 구조라면 Node 를 모두 설치해줘야 한다.
Manager 는 이들 Node 를 감시하고 이들 전체를 컨트롤하는 역활을 한다.
M-HA 특징
M-HA 를 AutoFailover 로 사용할만한 이유는 다음과 같다.
Short downtime
MySQL-Replication consistency
Easy Installation
No chagne to existing deployments
M-HA 를 고려할때에 중요한 부분이 짧은 다운타임이다. Master/Slave 구조에서 장애시에 Slave 를 Master 로 빠르게 승격을 시켜주어야 한다. 그래야만 두 서버간에 데이터가 달라지는 데이터 무결성이 깨지지 않게 된다. M-HA 는 비교적 이러한 데이터 무결성을 보장하기 위해서 많은 노력을 기울인 솔루션이라고 보면 된다.
M-HA 구성도
최소한의 환경에서 M-HA 를 구성도는 대략 다음과 같다.
M-HA Node 는 MySQL 이 설치된 서버라면 전부 설치해주어야 한다. M-HA Manager 는 외부서버에 설치해된다.
Node 설치
설치는 M-HA 구글 저장소에 가면 각 배포판별로 바이너리로 배포하고 있어 쉽게 설치가능하다. 여기서는 소스를 가지고 컴파일 설치하도록 하겠다.
Sun Jul1721:26:002016-[warning]Globalconfiguration file/etc/masterha_default.cnfnotfound.Skipping.
Sun Jul1721:26:002016-[info]Reading application defaultconfiguration from/usr/local/etc/mha.cnf..
Sun Jul1721:26:002016-[info]Reading server configuration from/usr/local/etc/mha.cnf..
Sun Jul1721:26:002016-[info]MHA::MasterMonitor version0.57.
Sun Jul1721:26:012016-[error][/usr/local/share/perl5/MHA/ServerManager.pm,ln188]There isno alive server.We can'tdofailover
Sun Jul1721:26:012016-[error][/usr/local/share/perl5/MHA/MasterMonitor.pm,ln427]Error happened on checking configurations.at/usr/local/share/perl5/MHA/MasterMonitor.pmline329.
Sun Jul1721:26:012016-[error][/usr/local/share/perl5/MHA/MasterMonitor.pm,ln525]Error happened on monitoring servers.
Sun Jul1721:26:012016-[info]Got exit code1(Notmaster dead).
MySQL Replication Health isNOTOK!
여기서 버그가 있다. /usr/local/share/perl5/MHA/DBHelper.pm 파일 198 라인에 $host 변수에 문제가 있다.
Mon Jul1801:30:492016-[warning]secondary_check_script isnotdefined.It ishighly recommended setting it tocheck master reachability from two ormore routes.
Mon Jul1801:30:492016-[info]Starting ping health check on192.168.96.32(192.168.96.32:3306)..
Mon Jul1801:30:492016-[debug]Connected on master.
Mon Jul1801:30:492016-[debug]Set shortwait_timeout on master:6seconds
위와같이 로그가 온다면 FailOver 가 정상적으로 된 것이다. 또, 로그 디렉토리 /var/log/masterha 디렉토리에 mha.failover.complete 파일이 생성되어 있을 것이다. 또한, manager 가 죽어 있다. 그러니까 FailOver 가 발생되면 다음과 같이 실행이 된다.
Slave 를 Master 로 승격시킨다.
Manager 에 지정한 로그 디렉토리에 mha.failover.complete 파일을 생성한다.
Manager 가 죽는다.
FailOver 가 발생할때마다 Manager 는 정해진 동작을 수행하고 자동으로 죽게 된다.
승격된 Master 서버에서는 다음을 체크해봐야 한다.
show slave status 명령을 입력했을때 아무것도 나오지 말아야 한다.
show variables like ‘%read%’ 명령어를 입력했을때에 read_only 값이 OFF 여야 한다.
maven 은 build timestamp 를 변수로 지원한다. 하지만 자세히 보면 이 timestamp 는 UTC timezone 에 맞춰져 있다. maven 에서 timestamp 는 기본적으로 UTC timezone 을 기반으로 한다. 그런데 이것을 다른 timezone 으로 변경할려면 어떻게 해야할까?
build-helper-maven-plugin
maven 에선 많은 plugin 을 지원한다. build-helper-maven-plugin 은 우리가 필요하는 기능인 timestamp 에 timezone 변경을 지원한다. 변경된 timezone 의 시간을 표시할 변수와 timestamp format, timezone 등을 지정하면 여기서 지정한 변수를 사용할 수 있게 된다.