최근 가요계는 여자 아이돌 ‘춘추전국시대’다. 2010년 일어난 일련의 사건만 봐도 가요계라는 패권을 차지하기 위한 이들의 경쟁이 얼마나 뜨거운 지 알 수 있다. 

‘Oh!’로 돌아온 소녀시대는 “지금은 소녀시대!”라는 그들의 구호처럼 컴백과 동시에 가요 프로그램에서 1위를 차지하는 등 가요계와 연예계를 넘나드는 왕성한 활동으로 가장 강력한 팬 기반을 구축하고 있다.

2NE1은 신곡 ‘날 따라 해봐요’를 공개해 각종 온라인 음원차트의 정상을 휩쓸며 소녀시대의 독주에 제동을 걸었다. 2007년 ‘텔미’로 춘추전국시대의 포문을 연 원더걸스는 항상 가운데서 첫 파트를 시작하던 ‘센터 자신감’ 선미의 탈퇴로 주춤했지만 발 빠른 대응으로 분위기 전환을 노리고 있다.

이외에도 애프터스쿨, 카라, 티아라, 브라운아이드걸스, 레인보우, f(x) 등이 왕좌를 차지할 기회를 호시탐탐 노리고 있다. 왕좌를 위해 아이돌 그룹이 준비하는 것은 파격적이면서도 어딘가 익숙한 노래와 노래를 압도할 수 있는 화려한 무대다.

그런데 무대를 효과적으로 구성하기 위한 요인은 뭘까. 무대의상? 비주얼 담당? 격렬한 안무? 모든 것이 ‘포인트’는 될 수 있겠지만 정말 중요한 것은 바로 ‘멤버 수’다. 각 멤버라는 점을 어떻게 배치하고 이동할 것인가가 안무의 핵심이 된다. 그렇다면 단순히 멤버의 숫자로만 봤을 때 무대 퍼포먼스에 가장 유리한 그룹은 어디일까. 단순하게 살펴보자.

● 짝수보다 홀수가 유리

먼저 짝수보다는 홀수가 유리하다. 아무리 무대 퍼포먼스를 멋있게 준비한다고 해도 모두 함께 부르거나 녹음된 코러스로 처리하는 후렴구가 아닌 이상 누군가 한명은 앞에 나와 노래를 불러야 한다. 이때 가장 안정적인 화면 구성은 좌우가 대칭이 되는 것이다. 즉 화면에 1, 3, 5, 7, 9명이 등장해야 자연스레 보인다.

그래서 3, 5, 7, 9명인 그룹은 무대를 구성하기 쉽다. 가운데서 홀로 노래를 부르더라도 카메라가 담는 범위에 따라 좌우 뒤쪽으로 다른 멤버가 균형 있게 배치된다. 특히 카메라가 무대를 담을 때는 단조로움을 배제하기 위해 거리를 달리해 한 사람을 가득 담는 ‘클로즈 업’부터 전체를 담는 ‘풀 샷’을 다양하게 활용하기 때문에 홀수로 이뤄진 그룹은 촬영이나 편집을 담당하는 스태프의 어깨도 한껏 가볍게 한다.

또한 홀수로 이뤄진 그룹은 각 멤버가 골고루 카메라에 잡힐 수 있게 한다. 만약 이들이 무대에 넓게 선다고 가정해보자. 그렇다면 모든 멤버가 1~3열로 서거나 V자 형태로 서는 경우를 생각할 수 있다. 멤버 수가 홀수라면 기본적으로 V자 형태는 어렵지 않다.

문제는 1~3열로 설 때다. 특히 멤버 수가 5명을 넘어가기 시작하면 특별한 경우를 제외하면 입체감 없이 1열로 서는 경우는 거의 없다. 워낙 좌우 폭이 넓기 때문에 카메라가 담기 어렵기 때문이다. 그래서 2열로 서는 경우가 많다.

홀수는 2열로 섰을 때 앞 열과 뒤 열의 수를 달리할 수 있어 정면 카메라로 촬영될 때 뒷사람이 가려지는 경우는 거의 없다. 예를 들어 ‘5=2+3’, ‘7=3+4‘, ’9=4+5‘으로 나눠 앞사람 사이의 공간에 뒷사람을 배치할 수 있는 셈이다.

이런 이유로 6명인 아이돌 그룹의 안무는 무대 주변의 카메라 위치와 움직임을 고려하지 않으면 불리할 수 있다. 한 명이 노래를 부를 때 다른 멤버의 위치가 균형을 이루지 않기 때문에 무대 전체를 잡는 풀 샷이 난감하다. 또 앞뒤로 3명씩 선다고 하면 정면과 좌우 45도 각도의 카메라에서는 뒤 열 가운데의 멤버는 앞의 세 사람에게 가려질 수밖에 없다. 

실제로 6명인 티아라는 ‘거짓말’로 데뷔했을 당시 한 멤버가 계속 가려지는 일을 겪기도 했다. 다행히 ‘보핍보핍’으로 컴백해 1위를 차지했을 때는 앞선 실수를 반복하지 않기 위해 무대구성에 심혈을 기울였다. 특히 노래를 부르는 사람이 중앙이 아닌 좌우 끝에 서도록 한 것도 획기적이었다.

비록 파트가 바뀔 때마다 카메라가 노래를 부르는 사람을 찾느라 우왕좌왕했지만 자연스레 45도 각도에서 찍는 카메라가 맨 앞에서 노래를 부르는 사람과 배경처럼 뒤에서 춤을 추는 멤버들을 담을 수 있었다. 또한 특정 멤버의 독무(단독 안무)를 중간 중간 배치해 단조로움을 없애는 방식도 선보였다. 결국 티아라는 ‘6=1+5’라는 전략으로 성공을 거둔 셈이다.


● 정삼각형, 정사각형, 정육각형, 정팔각형

정삼각형, 정사각형, 정육각형, 정팔각형은 자연 상태의 구조는 물론 인공적인 디자인에도 많이 애용된다. 안정적이고 견고하기 때문이다. 이런 도형은 아이돌 가수들의 안무에서도 종종 찾아볼 수 있다. 특히 ‘포인트’가 되거나 소위 ‘각을 맞춘 듯한 안무’를 할 때 등장한다. 

아이돌 그룹은 이런 도형을 만들기 위해 멤버 수만큼의 점을 ‘조립’한다. 이때도 간과해서 안 되는 사실은 ‘센터’=‘메인’=‘꼭짓점’이 되는 멤버가 있어야 한다는 점이다. 이런 도형을 만들기 위해서 멤버 수는 많을수록 좋다. 3~4명으로 이뤄지는 정삼각형은 아무래도 한명만 부각되기 때문이다.

정사각형을 가장 효과적으로 활용한 팀은 ‘미스터’로 1위를 차지했던 5인조 그룹 카라다. 이들은 ‘엉덩이춤’이라는 메인 안무를 역동적인 정사각형으로 표현했다. 바로 한 사람이 가운데 서고 다른 네 명이 정사각형으로 둘러싸고 엉덩이춤을 추며 회전하는 안무였다. 이 안무는 정면이나 좌우 45도는 물론 위에서 찍을 때도 견고하고 안정적인 균형과 대칭을 이뤘다.

정육각형은 ‘너 때문에’로 1위를 차지한 애프터 스쿨이 선보였다. 이들은 과거 6인조 그룹이었다가 1명이 빠진 뒤 2명을 영입하며 7인조 그룹이 돼 기존의 단조로운 무대 동선에서 탈피해 퍼포먼스가 다채로워졌다. 특히 노래 중 ‘갑갑갑해, 답답답해’ 부분에서는 한명이 중앙에 서고 다른 6명이 정육각형으로 둘러싸 벽을 만드는 안무를 선보이며 자연계에서 가장 단단하다는 벌집 구조를 가사와 맞는 안무에 차용하기도 했다.

정팔각형은 최근 ‘Oh’로 컴백한 소녀시대가 구사했다. ‘소몰이춤’이라 불리는 안무는 가운데 한명과 앞뒤좌우에 8명이 서서 천천히 앞으로 가는데 이때 정팔각형이 만들어진다. 자연 상태에서는 정육각형보다 불안정한 구조지만 각 멤버들이 키에 맞게 앞뒤로 서며 안정감을 더했다.

하지만 역동적인 정사각형과 달리 정육각형과 정팔각형 구조의 단점은 있다. 바로 뜻하지 않은 카메라 이동이다. 카라의 안무는 밖의 4명이 회전하며 카메라 회전에 자유롭다는 장점이 있다. 하지만 정면 카메라에서 가장 견고하고 안정적으로 보이는 정육각형과 정팔각형은 카메라가 좌우로 움직이면 구조가 제대로 보이지 않는다.

● 속도에 따른 인수분해와 이합집산

무대 퍼포먼스에서 빠뜨릴 수 없는 요소는 동선(動線)이다. 노래 파트에 따라 각 멤버가 카메라 가까이 나와야 하기 때문에 멤버 수가 많을수록 복잡할 확률이 크다. 7명이나 9명으로 이뤄진 그룹일 경우 동선을 미리 고려하지 않으면 단 한명의 실수로 무대 전체가 어그러질 수도 있다. 그래서 동선을 효율적으로 배치하기 위해 큰 수를 간단히 만드는 계산이 이뤄진다. 

사실 직관적으로는 수를 간단한 수의 곱셈으로 표현하는 인수분해가 이해하기는 쉽다. 하지만 엄밀히 말해 인수분해는 곱셉이 위주가 되기 때문에 오히려 ‘나머지 정리’나 단순한 뺄셈으로 생각하는 편이 옳다. 쉽게 표현하자면 각 멤버를 어떻게 가르고 묶어 동선을 짜느냐가 관건인 셈이다.

최근 활동 중인 7명 이상의 세 그룹을 보면 이들의 이합집산을 볼 수 있다. 9명으로 가장 숫자가 많은 소녀시대는 오히려 ‘9=3×3’으로 가장 단순한 동선을 만들었다. 즉 3명이 한 조가 되는 3팀을 만들어 3개 그룹의 동선으로 무대 이동이 이뤄진다. 개개인은 다른 8명의 동선을 고려할 필요 없이 다른 두 개 그룹의 동선만 고려하면 된다.

3명으로 이뤄진 팀은 한 명의 멤버가 노래를 부를 때도 위력을 발휘한다. 앞쪽 꼭짓점에 있는 사람이 노래를 부르면 자연히 뒤의 두 명이 좌우로 서게 돼 화면의 균형감을 이루게 한다. 또한 3개 팀이 다시 삼각형 형태로 서면 자연스레 좌우 대칭을 이루며 V자 또는 V자 안에 한 명이 서는 변형 V자로 바꾸기도 용이해진다. 각 멤버별로 부르는 파트의 길이가 짧기 때문에 위치를 빨리 바꿀 수 있는 동선이 필수적인 셈이다.

7명으로 이뤄진 레인보우와 씨야-다비치-티아라가 모인 프로젝트 그룹(여성시대2)도 멤버의 이합집산을 통해 동선을 구성한다. 하지만 둘의 이합집산은 구조 자체가 다르다. 각 멤버가 자리를 찾기 위해 움직이는 속도의 차이 때문이다.

레인보우는 주로 ‘7=3+2+2’의 구조를 취한다. 하지만 동선 자체는 세 그룹이 만드는 것치고는 단순하지는 않다. 이 구조에서 노래를 부르는 사람은 3명으로 이뤄진 그룹에 속해 있고 2명으로 이뤄진 그룹은 3명 그룹이 등장하기 위한 ‘문’의 역할을 한다. 그래서 이런 동선은 임팩트가 필요한 노래의 초반부나 종반부에 주로 등장하며 대개 V자 형태나 1열로 선 채 가운데에 서는 멤버만 바뀐다. 각 멤버의 파트가 워낙 짧다보니 다른 멤버들도 멀리 갈 수 없기 때문이다.

하지만 여성시대2는 ‘7=1+2×3’으로 나뉜다. 1명이 노래를 부르면 다른 6명은 2명씩 3팀 또는 3명씩 2팀으로 나뉘어 안무를 구성한다. 이들은 7명이지만 9명인 소녀시대 못지않게 무대를 넓게 사용한다. 각 멤버가 부르는 파트가 길다보니 빨리 움직이지 않아도 되며 동선도 길게 짤 수 있다. 어찌 보면 여성 아이돌 그룹은 멤버 수에서부터 강점과 약점을 갖고 시작하는 셈이다.
Posted by 솔라리스™
:









NT700Z5A-S78 모델과 
NT700Z5A-S58 모델에서 노트북에서 키보드 부분에 대한 문제사항이 

있습니다.  길이가 긴 키보드 자판.. 대표적으로 SPACE입니다. 타 노트북에서는 발생되지 않는 것인데 양쪽 사이드를 누르면 키보드가 동작하지 않습니다.



영상을 보시면 알게지만 커서는 글씨의 중간에 두고.. SPACE를 누르는데 반응하지 않습니다.
중심부를 누르면 동작을 합니다. A/S센터에서 동일기종으로 교환을 한뒤에 다시 한번 해보니..
헐.. 동일증상이 또 나오네요.

담당 A/S기사의 말.. 환불신청해 드릴까요 ??

일단 당시에는 별다른 대안이 없어서.. 일단 가지고 1층에 있는 디지털플라자로 가서 구매한 직원에게 애기를 했습니다. 그리고 전시되어 있던 노트북을 테스트 해보니.. 크로노스 모델 (  i5기종 )만 동일한 증상이 있더군요. 하지만 타 노트북의 경우에도 맨 끝을 눌러도 모두 동작을 하는데 
크로노스 기종만 이런 증상이 있습니다.

만일 이 문제가 금형이 잘못된것이라면.. 
금형수정비용도 수십억 ?
중국생산이기 때문에 춘절 휴가 다 지나고 ??
그리고 재 생산을 하거나.. 아니면 생산중단 및 모든 제품 회수 ??

제2의 옴니아가 나타나는 것일까요 ? 지금도 삼성울트라 광고만 엄청 나오는 군요. 울트라보다 이 기종이 더 상위 기종인데.. 크로노스 광고는 안하는 삼성..


 
Posted by 솔라리스™
:

Web Technology Stack [Analysis]

NoSQL 2011. 8. 10. 13:25 |

Even wondered what technologies are used for large web applications which have millions of unique visitors and have 1000s of requests per second. Which programming languages are making it happen, handling such peak amount of load at a time. We were curious about it and thought lets figure out what beneath the nice slick interface, who is handling the business logic efficiently. Here is what we found, a compiled list of technologies stack used at various web applications.

 
Product Front End Back end Database Others
Twitter Ruby on Rails (RoR), JavaScript, jQuery
LabJS, Modernizr, JSON-P, oEmbed
Scala Cassandra Java, C, Python, Mustache templating language
Facebook PHP, XHP, Hiphop for PHP, JavaScript C, C++, Java Cassandra, MySQL Python, Erlang
LinkedIn JSP, Apache Coyote Web Server Spring MVC, Linkedin spring, grails, Oracle and MySQL ActiveMQ for JMS, Lucene as a foundation for search, DWR, Jetty, Eh-cache, Quartz, Spring remoting.
YahooMail HTML, CSS, JavaScript (with YUI 3) PHP MySQL Apache Traffic Server (formely known as Yahoo! Traffic Server).
Google + Closure framework, including Closure’s JavaScript compiler and template system, HTML5 History API Closure templates server-side, C++, Java, or Python BigTable and Colossus/GFS MapReduce
FourSquare scala(lift framework) scala

Amazon S3 for hosting, /img/ folder which is served by nginx directly

MongoDB load balancer(s): nginx/0.8.52

Lift- A web framework written in scala.

Youtube Python psyco, a dynamic python->C compiler MySQL
Quora Python and JavaScript LiveNode/webnode2, Thrift (Communicate to backend)

Amazon EC2 and S3 for hosting

MySQL + memcached C++
Load Balancing: nginx in front of HAProxy
Viddler PHP, Python Rails 2.x, ffmpeg/mencoder/x264lib, Java 1.6 / Spring / Hibernate / ehcache, Erlang

Amazon EC2 and S3 for hosting

Mysql 5.0 Hadoop HDFS (distributed video source storage)
Nginx/Keepalived (Load balancers for all web traffic)
Wowza (RTMP video recording server)
Mediainfo(reporting video metadata)
Yamdi (metadata injector for flash videos)
Puppet(configuration management)
Logcheck(log scanning)
Duplicity(backup)
StackOverFlow jQuery, ASP .NET C#, Microsoft ASP.NET (version 4.0), ASP.NET MVC 3, Razor. LINQ to SQL, some raw SQL Server HAProxy (for load balancing), Bacula(for backup), Redis(caching layer)
Disqus jQuery,EasyXDM, Sammy, Flot, Raphaël, JSHint Python scripts, Django, Celery, South PostgreSQL, memcached HAProxy + heartbeat (Load balancing)

 

In Short..

Database Distribution

Backend Technology Distribution

Conclusion

The current trends for front end development are mainly jQuery, Python, Scala. Though some companies use Microsoft technologies but, the percentage of such companies is very less. Although MySQL and Cassandra has been favorites databases but few are moving to MongoDB which is a NoSQL database. Back end of these high scaling sites run on variety of different technologies such as Django, python, RoR, Closure, C++, Java, Scala etc.

I’ve written this post to give insights about which technology combinations are preferred by websites with high user base, you might want to consider these points while choosing platforms and programming languages for your start-up.

Like this article? or have some thing to say? Comment down your opinions.


http://www.tutkiun.com/2011/07/web-technology-stack-analysis.html

Posted by 솔라리스™
:

Introduction

MongoDB 1.6 was released today, and it includes, among other things it includes support for the incredible sexy replica sets feature – basically master/slave replication on crack with automatic failover and the like. I’m setting it up, and figured I’d document the pieces as I walk through them.

My test deploy is going to consist of two nodes and one arbiter; production will have several more potential nodes. We aren’t worrying about sharding at this point, but 1.6 brings automatic sharding with it, as well, so we can enable that at a later point if we need to.

Installation

Installation is very easy. 10gen offers a yum repo, so it’s as easy as adding the repo to /etc/yum.repos.d and then running yum install mongo-stable mongo-server-stable.

Once installed, mongo --version confirms that we’re on 1.6. Time to boot up our nodes.

Configuration

For staging, we’re going to run both replica nodes and the arbiter on a single machine. This means 3 configs.

I have 3 config files in /etc/mongod/mongo.node1.conf, mongo.node2.conf, and mongo.arbiter.conf. As follows:

1  
2
3
4
5
6
7
8
 
# mongo.node1.conf
replSet=my_replica_set
logpath=/var/log/mongo/mongod.node1.log
port = 27017
logappend=true
dbpath=/var/lib/mongo/node1
fork = true
rest = true
 
1  
2
3
4
5
6
7
 
# mongo.node2.conf
replSet=my_replica_set
logpath=/var/log/mongo/mongod.node2.log
port = 27018
logappend=true
dbpath=/var/lib/mongo/node2
fork = true
 
1  
2
3
4
5
6
7
8
# mongo.arbiter.conf
replSet=my_replica_set
logpath=/var/log/mongo/mongod.arbiter.log
port = 27019
logappend=true
dbpath=/var/lib/mongo/arbiter
fork = true
oplogSize = 1

Starting it up

Then we just fire up our daemons:

2
3
mongod -f /etc/mongod/mongo.node1.conf
mongod -f /etc/mongod/mongo.node2.conf
mongod -f /etc/mongod/mongo.arbiter.conf

Once we spin up the servers, they need a bit to allocate files and start listening. I tried to connect a bit too early, and got the following:

2
3
4
5
[root@261668-db3 mongo]# mongo
MongoDB shell version: 1.6.0
connecting to: test
Fri Aug  6 03:48:40 Error: couldn't connect to server 127.0.0.1} (anon):1137
exception: connect failed

Configuring replica set members

Once you can connect to the mongo console, and we need to set up the replica set. If you have a compliant configuration, then you can just call rs.initiate() and everything will get spun up. If you don’t, though, you’ll need to specify your initial configuration.

This is where I hit my first problem; the hostname as the system defines it didn’t resolve. This was resulting in the following:

2
3
4
5
6
7
 
8
9
[root@261668-db3 init.d]# mongo --port 27017
MongoDB shell version: 1.6.0
connecting to: 127.0.0.1:27017/test
> rs.initiate();
{
        "info2" : "no configuration explicitly specified -- making one",
        "errmsg" : "couldn't initiate : need members up to initiate, not ok : 261668-db3.db3.domain.com:27017",
        "ok" : 0
}

The solution, then, is to specify the members, and to use a resolvable internal name. Note that you do NOT include the arbiter’s information; you don’t want to add it to the replica set early as a full-fledged member.

1  
2
3
4
5
6
> cfg = {_id: "my_replica_set", members: [{_id: 0, host: "db3:27017"}, {_id: 1, host: "db3:27018"}] }
> rs.initiate(cfg);
{
        "info" : "Config now saved locally.  Should come online in about a minute.",
        "ok" : 1
}

Bingo. We’re in business.

Configuring the replica set arbiter

If the replica set master fails, a new master is elected. To be elected, a replica master needs to have at least floor(n / 2) + 1 votes, where n is the number of active nodes in the cluster. In a paired setup, if the master were to fail, then the remaining slave wouldn’t be able to elect itself to the new master, since it would only have 1 vote. Thus, we run an arbiter, which is a special lightweight, no-data-contained node whose only job is to be a tiebreaker. It will vote with the orphaned slave and elect it to the new master, so that the slave can continue duties while the old master is offline.

1  
2
3
4
5
6
> rs.addArb("db3:27019")
{
        "startupStatus" : 6,
        "errmsg" : "Received replSetInitiate - should come online shortly.",
        "ok" : 0
}

Updated driver usage

Once we’re set up, the Ruby Mongo connection code is updated to connect to a replica set rather than a single server.

Before:

MongoMapper.connection = Mongo::Connection.new("db3", 27017)

After

MongoMapper.connection = Mongo::Connection.multi([["db3", 27017], ["db3", 27018]])

This will attempt to connect to each of the defined servers, and get a list of all the visible nodes, then find the master. Since you don’t have to specify the full list, you don’t have to update your connection info each time you change the machines in the set. All it needs is at least one connectable server (even a slave) and the driver will figure out the master from there.

Conclusion

That’s about all there is to it! We’re now up and running with a replica set. We can add new slaves to the replica set, force a new master, take nodes in the cluster down, and all that jazz without impacting your app. You can even set up replica slaves in other data centers for zero-effort offsite backup. If your DB server exploded, you could point your app at the external datacenter’s node and keep running while you replace your local database server. Once your new server is up, just bring it online and re-add its node back into your replica set. Data will be transparently synched back to your local node. Once the sync is complete, you can re-elect your local node as the master, and all is well again.

Congratulations – enjoy your new replica set!

출처 : http://www.coffeepowered.net/2010/08/06/setting-up-replica-sets-with-mongodb-1-6/ 

Posted by 솔라리스™
:

Replica Set Tutorial

NoSQL/mongoDB 2011. 7. 8. 15:55 |

This tutorial will guide you through the basic configuration of a replica set. Given the tutorial is an example and should be easy to try, it runs several mongod processes on a single machine (in the real world one would use several machines). If you are attempting to deploy replica sets in production, be sure to read the replica set documentation. Replica sets are available in MongoDB V1.6+.

Introduction

A replica set is group of n mongod nodes (members) that work together. The goal is that each member of the set has a complete copy (replica) of the data form the other nodes.

Setting up a replica set is a two-step process that requires starting each mongod process and then formally initiating the set. Here, we'll be configuring a set of three nodes, which is standard.

Once the mongod processes are started, we will issue a command to initialize the set. After a few seconds, one node will be elected master, and you can begin writing to and querying the set.

Starting the nodes

First, create a separate data directory for each of the nodes in the set. In a real environment with multiple servers we could use the default /data/db directory if we wanted to, but on a single machine we will have to set up non-defaults:

$ mkdir -p /data/r0
$ mkdir -p /data/r1
$ mkdir -p /data/r2

Next, start each mongod process with the --replSet parameter. The parameter requires that you specify a logical name for our replica set. Let's call our replica set "foo". We'll launch our first node like so:

$ mongod --replSet foo --port 27017 --dbpath /data/r0

Let's now start the second and third nodes:

$ mongod --replSet foo --port 27018 --dbpath /data/r1
$ mongod --replSet foo --port 27019 --dbpath /data/r2

You should now have three nodes running. At this point, each node should be printing the following warning:

Mon Aug  2 11:30:19 [startReplSets] replSet can't get local.system.replset config from self or any seed (EMPTYCONFIG)

We can't use the replica set until we've initiated it, which we'll do next.

Initiating the Set

We can initiate the replica set by connecting to one of the members and running the replSetInitiate command (that is,rs.initiate() in the mongo shell). This command takes a configuration object that specifies the name of the set and each of the members.

The replSetInitiate command may be sent to any member of an uninitiated set. However, only the member performing the initiation may have any existing data. This data becomes the initial data for the set. The other members will begin synchronizing and receiving that data (if present; starting empty is fine too). This is called the "initial sync". Secondaries will not be online for reads (in state 2, "SECONDARY") until their initial sync completes.

Note: the replication oplog (in the local database) is allocated at initiation time. The oplog can be quite large, thus initiation may take some time.

$ mongo localhost:27017
MongoDB shell version: 1.5.7
connecting to: localhost:27017/test
> rs.help(); // if you are curious run this (optional)
>
> config = {_id: 'foo', members: [
                          {_id: 0, host: 'localhost:27017'},
                          {_id: 1, host: 'localhost:27018'},
                          {_id: 2, host: 'localhost:27019'}]
           }
> rs.initiate(config);
{
   "info" : "Config now saved locally.  Should come online in about a minute.",
   "ok" : 1
}

We specify the config object and then pass it to rs.initiate(). Then, if everything is in order, we get a response saying that the replica set will be online in a minute. During this time, one of the nodes will be elected master.

To check the status of the set, run rs.status():

> rs.status()
{
	"set" : "foo",
	"date" : "Mon Aug 02 2010 11:39:08 GMT-0400 (EDT)",
	"myState" : 1,
	"members" : [
		{
			"name" : "arete.local:27017",
			"self" : true,
		},
		{
			"name" : "localhost:27019",
			"health" : 1,
			"uptime" : 101,
			"lastHeartbeat" : "Mon Aug 02 2010 11:39:07 GMT-0400",
		},
		{
			"name" : "localhost:27018",
			"health" : 1,
			"uptime" : 107,
			"lastHeartbeat" : "Mon Aug 02 2010 11:39:07 GMT-0400",
		}
	],
	"ok" : 1
}

You'll see that the other members of the set are up. You may also notice that the myState value is 1, indicating that we're connected to the member which is currently primary; a value of 2 indicates a secondary.

You can also check the set's status in the HTTP Admin UI.

Replication

Go ahead and write something to the master node:

  db.messages.insert({name: "ReplSet Tutorial"});

If you look at the logs on the secondary nodes, you'll see the write replicated.

Failover

The purpose of a replica set is to provide automated failover. This means that, if the primary node goes down, a secondary node can take over. When this occurs the set members which are up perform an election to select a new primary. To see how this works in practice, go ahead and kill the master node with Control-C (^C) (or if running with --journal, kill -9 would be ok too):

^CMon Aug  2 11:50:16 got kill or ctrl c or hup signal 2 (Interrupt), will terminate after current cmd ends
Mon Aug  2 11:50:16 [interruptThread] now exiting
Mon Aug  2 11:50:16  dbexit: 

If you look at the logs on the secondaries, you'll see a series of messages indicating fail-over. On our first slave, we see this:

Mon Aug  2 11:50:16 [ReplSetHealthPollTask] replSet info localhost:27017 is now down (or slow to respond)
Mon Aug  2 11:50:17 [conn1] replSet info voting yea for 2
Mon Aug  2 11:50:17 [rs Manager] replSet not trying to elect self as responded yea to someone else recently
Mon Aug  2 11:50:27 [rs_sync] replSet SECONDARY

And on the second, this:

Mon Aug  2 11:50:17 [ReplSetHealthPollTask] replSet info localhost:27017 is now down (or slow to respond)
Mon Aug  2 11:50:17 [rs Manager] replSet info electSelf 2
Mon Aug  2 11:50:17 [rs Manager] replSet PRIMARY
Mon Aug  2 11:50:27 [initandlisten] connection accepted from 127.0.0.1:61263 #5

Both nodes notice that the master has gone down and, as a result, a new primary node is elected. In this case, the node at port 27019 is promoted. If we bring the failed node on 27017 back online, it will come back up as a secondary.

Changing the replica set configuration

There are times when you'll want to change the replica set configuration. Suppose, for instance, that you want to make a member have priority zero, indicating the member should never be primary. To do this, you need to pass a new configuration object to the database's replSetReconfig command. The shell rs.reconfig() helper makes this easier.

One note: the reconfig command must be sent to the current primary of the set. This implies that you need a majority of the set up to perform a reconfiguration.

> // we should be primary.  can be checked with rs.status() or with:
> rs.isMaster();
> var c = rs.conf();
{_id: 'foo', members: [
                       {_id: 0, host: 'localhost:27017'},
                       {_id: 1, host: 'localhost:27018'},
                       {_id: 2, host: 'localhost:27019'}]
}
> c.members[2].priority = 0;
> c
{_id: 'foo', members: [
                       {_id: 0, host: 'localhost:27017'},
                       {_id: 1, host: 'localhost:27018'},
                       {_id: 2, host: 'localhost:27019', priority: 0}]
}
> rs.reconfig(c);
> //done. to see new config,and new status:
> rs.conf()
> rs.status()

Running with two nodes

Suppose you want to run replica sets with just two database servers (that is, have a replication factor of two). This is possible, but as replica sets perform elections, here a majority would be 2 out of 2 which is not helpful. Thus in this situation one normally also runs an arbiter on a separate server. An arbiter is a set member which has no data but gets to vote in elections. In the case here, the arbiter is the tie breaker in elections. Arbiters are very lightweight and can be ran anywhere – say, on an app server or a micro vm. With an arbiter in place, the replica set will behave appropriately, recovering automatically during both network partitions and node failures (e.g., machine crashes).

You start up an arbiter just as you would a standard replica set node, as a mongod process with the --replSet option. However, when initiating, you need to include the arbiterOnly option in the config document.

With an arbiter, the configuration presented above would look like this instead:

config = {_id: 'foo', members: [
                          {_id: 0, host: 'localhost:27017'},
                          {_id: 1, host: 'localhost:27018'},
                          {_id: 2, host: 'localhost:27019', arbiterOnly: true}]
           }

Drivers

Most of the MongoDB drivers are replica set aware. The driver when connecting takes a list of seed hosts from the replica set and can then discover which host is primary and which are secondary (the isMaster command is used internally by the driver for this).

With this complete set of potential master nodes, the driver can automatically find the new master if the current master fails. See your driver's documentation for specific details.

If you happen to be using the Ruby driver, you may want to check out Replica Sets in Ruby.

참고 : http://mongodb.onconfluence.com/display/DOCSKR/Home ( 한국어 메뉴얼 )
           http://groups.google.com/group/mongodb-kr ( 한국 MongoDB 사용자 그룹 ) 
 



Posted by 솔라리스™
: