cloudera 5.5.1의 hadoop 2.6.0 버전을 설치하고 싶다면, 아래 싸이트에 접속해서

hadoop-2.6.0+cdh5.5.1+924-1.cdh5.5.1.p0.15.el6.x86_64.rpm를 다운로드한 후 설치한다. 

https://archive.cloudera.com/cdh5/redhat/6/x86_64/cdh/5.5.1/RPMS/x86_64/ 

막상 설치하려면, 아래와 같은 에러가 발생한다. 

경고: hadoop-2.6.0+cdh5.5.1+924-1.cdh5.5.1.p0.15.el6.x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID e8f86acd: NOKEY

오류: Failed dependencies:

bigtop-utils >= 0.7 is needed by hadoop-2.6.0+cdh5.5.1+924-1.cdh5.5.1.p0.15.el6.x86_64

zookeeper >= 3.4.0 is needed by hadoop-2.6.0+cdh5.5.1+924-1.cdh5.5.1.p0.15.el6.x86_64

avro-libs is needed by hadoop-2.6.0+cdh5.5.1+924-1.cdh5.5.1.p0.15.el6.x86_64

parquet is needed by hadoop-2.6.0+cdh5.5.1+924-1.cdh5.5.1.p0.15.el6.x86_64

따라서, RPM을 따라하면 엄청 쉽지 않은 작업이 계속 연결되어 있다 .

한번 제대로 설치한 후, 꼭 tar.gz으로 묶어 들고 공유 디렉토리에 잘 저장해 두어야 한다.. 

for yield 첫번째 예시 다음 공부이다

http://knight76.tistory.com/entry/scala-for-%EB%AC%B8-yield

list에 for yield를 사용한 예시이다.

간단한 for 코드이다. if 문은 for에 존재할 수도 있고, for 문 블럭 안에 존재할 수 있다.

for {
  i <- 1 to 4 //1,2,3,4
  if i % 2 == 0
} print(i)
println

결과는 24이다.

그런데, 컬렉션(List)라면 상황이 좀 달라진다. 컬렉션으로 비슷하게 코딩하면 에러가 발생한다.

//  에러 : Error:(37, 3) '<-' expected but '}' found.
//  for {
//    i <- list
//    i % 2 == 0
//  } println(i)

다음처럼 바꿔야 잘 동작한다.

val list = List(1, 2, 3, 4)
for (i <- list) {
  print(i)
}
println

결과는 다음과 같다.

List에 for yield를 간단하게 사용할 수 있다.

print(for (i <- list) yield i * 2)
println

결과는 다음과 같다.

여기에 if문을 추가한 코드이다. if문을 안에 넣을 수 있지만, for 문장에 포함시킬 수 있다.

for (i <- list) {
  if (i % 2 == 0) print(i)
}
println

for (i <- list if i % 2 == 0) {
  print(i)
}
println

결과는 동일하게 24이다.

for문은 내부적으로 sugar스럽게 사용할 수 있다. 이를 scala's for comprehension(for 내장, 오현석님이 이미 이렇게 번역하셔서;; )이라고 한다. 스칼라 컴파일러가 for 코드를 내부적으로 flatMap 또는 forEach로 변경됨을 의미하는 개념이라 할 수 있다. 

// scala's comprehension
println(for(x <- List(1) ; y <- List(1,2,3)) yield (x,y))
println(List(1).flatMap(x => List(1,2,3).map(y => (x,y))))

결과는 다음과 같다.

replica 구성한 mongodb(wiredTiger)의 3.2.0을 3.2.10으로 버전업한 내용을 설명한다. (별 내용은 아니지만..)

replica 버그가 의심되는 부분이 있어서 버전업을 진행했다.

관련 내용 : http://knight76.tistory.com/entry/mongodb-32%EC%9D%98-slave%EC%9D%98-recovering-%EC%83%81%ED%83%9C-%EB%B3%B5%EA%B5%AC%ED%95%98%EA%B8%B0

먼저 slave 한대에 서버에 접속해서 shutdown한다. (그냥 kill 하면 pid 파일도 같이 지워야 하니. 이 명령대로 사용하는 것이 좋다.

$mongo

> use admin

>db.shutdownServer({timeoutSecs: 1});

새로운 mongodb를 설치한다. 나는 SSL을 지원하지 않는 linux x386 64 비트 파일(mongodb-linux-x86_64-3.2.10.tgz)를 설치했기 때문에, 3.2.10에 맞춰 다운로드했다.

$ which mongo

/usr/local/mongodb/bin/mongo

$ sudo tar zxvf mongodb-linux-x86_64-3.2.10.tgz

$ sudo chown -R www:www mongodb-linux-x86_64-3.2.10

$ sudo rm mongodb

$ sudo ln -sf mongodb-linux-x86_64-3.2.10 mongodb

이제 데몬을 재실행한다.

설정 파일을 항상 따로 두어야. 업그레이드시 손이 덜 간다.

$ /usr/local/mongodb/bin/mongod -f /etc/mongod.conf

테스트해본다.

$ mongo

MongoDB shell version: 3.2.10

connecting to: test

replset:SECONDARY> rs.status()

..

정상적이다.

이렇게 다른 slave, master에 적용하고, 마지막에 rs.status()로 제대로 동작되는지 확인한다.

참고

https://docs.mongodb.com/manual/reference/command/shutdown/