좋은회사. 나에게 열광하게 만들자

큐브리드 복제환경 구성후 복제에이전트가 구동되지 않을때

(노랑배) — Wed, 04 Aug 2010 10:29:30 +0900

마스터 + 배포 + 슬레이브 서버로 구성

구성후 복제에이전트를 구동하면 슬레이브 디비에 연결되지 못하고 에이전트가 다운됨

배포서버에 이런 에러가 나옵

[Tue Aug 3 13:45:42 2010] : ERROR(178023): can't connect to the slave. - demodb2
[Tue Aug 3 14:15:30 2010] : ERROR(178023): can't connect to the slave. - demodb2
[Tue Aug 3 14:39:14 2010] : ERROR(178023): can't connect to the slave. - demodb2
[Tue Aug 3 17:16:32 2010] : ERROR(178023): can't connect to the slave. - demodb2

확인할 사항 1
배포DB에 dba 로 접속해서 select * from slave_info 결과 중 master_ip 값이 실제 슬레이브DB의 정보와 동일한지 확인 필요

확인할 사항 2
마스터 서버와 슬래이브 서버간 통신 상태를 확인. 배포데이터베이스 구성시 복제 서버 포트를 지정했을 것인데 관련 포트의 연결이 가능한지를 확인해 본다. 또한 복제 서버가 구동되었는지도 확인한다.

확인할 사항 3
배포서버 $CUBRID_DATABASES/databases.txt에 슬레이브 서버정보가 들어갔는지 확인한다. 없는 경우 슬레이브 디비 정보를 추가해주고, localhost 부분에 슬레이브 서버 아이피나 호스트네임으로 해준다.

실제 서비스에서 nginx 이용하기

(노랑배) — Fri, 23 Jul 2010 14:59:27 +0900

동영상 링크 : http://www.mgoon.com/view.htm?id=1173457

CUBRID에서 제약조건(PK,FK,UNIQUE),index 설정 시 주의 사항

(노랑배) — Fri, 23 Jul 2010 11:15:57 +0900

출처 : http://blog.naver.com/cubebridge?Redirect=Log&logNo=20096666579

변별력이 떨어지는 index는 insert의 성능을 크게 저하시킵니다.
변별력이 떨어지는 index란? index의 분포가 좋지 않은 것으로 칼럼의 값이 하나의 값으로 몰려있거나 적은 수의 값이 많은 량의 데이터를 차지하는 경우입니다.

테스트현황:

500만건의 데이터를 변별력이 없는 index가 설정되어 있는 경우와 변별이 있는 index가 설정되어 있는 경우로 나줘 TPS와 QPS를 비교한 결과를 바탕으로 설명합니다.

측정수단:

cubrid broker status -b로 TPS,QPS를 확인합니다.

테이블 상태:

1. 테이블에 index 3개가 설정되어 있습니다.

2. PK, UNIQUE, FK 키가 있으며, FK가 참조하고 있는 테이블은 단 하나의 값('0')을 가지고 있습니다.

3. insert문이 수행 될수록 FK칼럼에 값은 계속적으로 '0'이 입력되도록 되어있습니다.

변별력 없는 FK가 있는 상태로 진행(FK는 index이다.)

테스트 시작:

JDBC를 이용하여, insert문 데이터를 500만건이 입력되도록 설정합니다.

초기(REQ 319442)

NAME PID PORT AS JQ REQ TPS QPS LONG-T LONG-Q ERR-Q
=========================================================================

* broker1 13487 33000 50 0 319442 2004 4009 0/60.0 0/60.0 0

* broker1 13487 33000 50 0 321448 2005 3990 0/60.0 0/60.0 0

...

시작 후 중반(REQ 2438861)

NAME PID PORT AS JQ REQ TPS QPS LONG-T LONG-Q ERR-Q
=========================================================================

* broker1 13487 33000 49 0 2438861 619 1237 0/60.0 0/60.0 0

* broker1 13487 33000 49 0 2439473 612 1224 0/60.0 0/60.0 0

...

위의 결과에 따르면 200만건 데이터 입력으로 인하여 최초의 TPS,QPS가 약 1/3수준으로 감소됩니다.

FK제거 후 테스트 진행

초기(REQ 97981)

NAME PID PORT AS JQ REQ TPS QPS LONG-T LONG-Q ERR-Q
=========================================================================

* broker1 14106 33000 50 0 97981 1643 3301 0/60.0 0/60.0 0

* broker1 14106 33000 50 0 100001 2018 4046 0/60.0 0/60.0 0
...

시작 후 중반(REQ 2604250)

NAME PID PORT AS JQ REQ TPS QPS LONG-T LONG-Q ERR-Q
=========================================================================

* broker1 14106 33000 50 0 2604250 1539 3064 0/60.0 0/60.0 0

* broker1 14106 33000 50 0 2605882 1629 3292 0/60.0 0/60.0 0

...

변별력이 떨어지는 FK삭제 후 테스트 결과 TPS, QPS의 미미한 감소는 있으나 큰 차이가 없는 것으로 확인됩니다.

FK도 index로 등록이 되므로 변별력이 떨어지는 FK의 경우 insert성능에 상당한 영향을 주는 것으로 파악됩니다.

따라서, DB생성 시 FK에 해당 하는 값이 변별력이 높지 않다면, FK를 설정하는 것을 지양하고 우회안이나 차선책을 찾는 것이 필요합니다

[출처] CUBRID에서 제약조건(PK,FK,UNIQUE),index 설정 시 주의 사항|작성자 Gee

Advanced Bash-Scripting Guide

(노랑배) — Wed, 07 Jul 2010 17:06:32 +0900

bash 스크립트 매뉴얼.. 아주 좋음

http://tldp.org/LDP/abs/html/index.html

Detected aborted journal 오류시 해결법-EXT3-fs error (device sda2) ext3_journal_start_sb : Detected aborted journal

(노랑배) — Mon, 05 Jul 2010 11:17:30 +0900

EXT3-fs error (device sda2) ext3_journal_start_sb : Detected aborted journal
EXT3-fs error (device sda2) ext3_journal_start_sb : Detected aborted journal
EXT3-fs error (device sda2) ext3_journal_start_sb : Detected aborted journal

에러가 발생하면 읽기모드로 변경되면서 더이상 업데이트가 안된다.

해결방법

1. 해당장치를 unmount

2. debugfs -w -R "feature ^has_journal,^needs_recovery" /dev/장치명
파티션을 ext2모드로 바꾸어 줍니다.

3. fsck -y /dev/장치명
점검

4. tune2fs -j /dev/장치명
저널링을 활성화

5. mount

파워에 의한 디스크 에러 메시지-EXT3-fs error (device sda2) in start_transaction: Journal has aborted

(노랑배) — Mon, 05 Jul 2010 11:08:05 +0900

EXT3-fs error (device sda2) in start_transaction: Journal has aborted
EXT3-fs error (device sda2) in start_transaction: Journal has aborted

위와같은 에러 메시지가 발생되면서 특정 파티션이나 혹은 모든 파티션이 읽기모드로(Read Only mode) 변경된다. 이러면서 업데이트가 불가능해지는데... 원인은 아래와 같다.

1. 파워 불량
2. 일시적인 전원 불량
3. 비정상적인 서버 종료

Instructions

Things You'll Need:

A linux Rescue CD, like SysRescueCD or a bootable OS from CD or disk, like Tomcat.

Step 1

Reboot the server, and watch for the moment when it asks you to push "Y" to start a filesystem check, and let it cleanup the system. If you never get the opportunity to do the "Y" selection because it shows a message of some kind about a panic or kernel panic (locks up), then physically power down the server, and power it up, and now watch for the opportunity to push the "Y", for Yes.
Step 2

Once the server has booted, then immediately either login and tell it to reboot by issuing the command of "reboot", or by simply pushing Ctrl-Alt-Del, which will initiate a reboot process.
Step 3

Go into server's boot Bios. Do not allow the server to get past the memory check stage and push the needed key to go into the PC bios. Usually, it is the "Del" or Delete Key, as indicated by a message near the bottom of the screen.
Step 4

Find the appropriate bios settings (probably advanced bios settings), and change it's boot drive or first boot disk to be the CDROM (make a note of the current disk setting before you change it). Save the changed settings and exit the bios menu with that new setting saved.
Step 5

Let the server restart and boot off of a Rescue Cd like SysRescueCD.
Step 6

Optional step. You can make use of such commands as "fdisk -l" to help you determine or refresh your memory of which partition name you will be referring to (for this example, it will be hda2, as indicated by the original error message stated in the Problem definition).
Step 7

Now remove the journal from that partition's filesystem, fs, (this turns it into a ext2 fs, instead of a ext3 fs). This is done with the command of "tune2fs -O ^has_journal /dev/hda2"
Step 8

Optional step if you have done the above cleanup indicated and rebooted immediately after a successful boot: Now cleanup the partition by running "e2fsck -y /dev/hda2". The -y options simply means for the answer to be a yes to everytime it wants to make a fix, and that could be dozens of fixes. If your SysRescueCD or e2fsck is older than what some Fedora and other linux OS use (the OS on your hard drive), then this step may not be doable, and thus the reason I had you do the above steps to cleanup using the installation's own e2fsck program, which is what gets used when you push "Y" in the above step.
Step 9

Now create a journal again with "tune2fs -j /dev/hda2"
Step 10

Issue the command "reboot" and again go into the bios as indicated in Step 3 above and set the Boot Disk or First Boot Drive to be the original setting (probably something like hd0). Save the changed settings and exit the bios menu with that new setting saved.
Step 11

Now the server should boot fine, and you should no longer see the EXT3-fs error occurring.

Nortel-Alteon 패스워드 리셋하기

(노랑배) — Tue, 29 Jun 2010 09:18:03 +0900

forgetMe!

ID : admin
P/W : forgetMe!

콘솔로 접속한다.

nginx 웹서버에서 파일 업로드시 "413 Request Entity Too Large" 오류 날 때

(노랑배) — Mon, 31 May 2010 15:50:18 +0900

nginx 웹서버에서 파일 업로드시 "413 Request Entity Too Large" 오류 날 때

# nginx error
2010/05/31 14:58:09 [error] 6524#0: *31 client intended to send too large body: 5399571 bytes, client: {IP}, {hostname}, request: "POST /adm_common/ HTTP/1.1", host: "{hostname}", referrer:"{http://referrer}'

아래 설정에서 client_max_body_size 1m; 설정을 수정 후 nginx를 재시작 한다.

http {
client_body_in_file_only off;
client_body_buffer_size 16k;
client_body_temp_path /var/tmp/nginx/client_temp 1 2
client_body_timeout 60;
client_header_buffer_size 1k;
client_header_timeout 60;
client_max_body_size 1m;

큐브리드 에러코드 -81 (cubrid error code = -81)

(노랑배) — Wed, 12 May 2010 20:13:21 +0900

# 큐브리드 에러 코드
error code = -81

# 큐브리드 버전 : 8.2.2

# 에러내용
Time: 05/12/10 19:43:18.316 - FATAL ERROR *** ERROR CODE = -81, Tran = 2, CLIENT = (unknown):(system)(-1), EID = 1
Internal error: logical log page 1121169 may be corrupted.

*** The previous error message is the last one. ***

논리적인 문제로 페이지가 손상된 상황으로 보여짐
백업된 데이터를 확인하여 restoredb로 복구가 가능함
복구시 메세지 시간을 파악하고 -d 옵션으로 안정된 시간으로 복구하면 된다.
데이터는 손실될 수 있으니 먼저 백업받으면 좋음

# 명령어 예
cubrid restoredb -d 05-11-2008:10:58:00 --level 0 -p 디비명

nginx 504 gateway time-out

(노랑배) — Thu, 01 Apr 2010 10:01:00 +0900

I am running Django, FastCGI, and Nginx. I am creating an api of sorts that where someone can send some data via XML which I will process and then return some status codes for each node that was sent over.

The problem is that Nginx will throw a 504 Gateway Time-out if I take too long to process the XML -- I think longer than 60 seconds.

So I would like to set up Nginx so that if any requests matching the location /api will not time out for 120 seconds. What setting will accomplish that.

What I have so far is:

    # Handles all api calls 
    location ^~ /api/ { 
        proxy_read_timeout 120; 
        proxy_connect_timeout 120; 
        fastcgi_pass 127.0.0.1:8080; 
    }

Edit: What I have is not working :)