서버가 잠겨 있거나 비정상적인 상태로 SQL Server에 연결이 되지 않는 경우

 

DAC 접근을 위한 설정

remote admin connection 옵션을 활성화

SSMS -> DB 인스턴스 우클릭 -> 패싯(A) 클릭

패싯 속성(P) -> 'RemoteDacEnabled' Ture 설정

스크립트 적용

SP_CONFIGURE 'remote admin connections', 1
GO
 
RECONFIGURE
GO

DAC 접근 방법

cmd창에서 sqlcmd 명령어로 접속

cmd> sqlcmd -S localhost -U sa -P [패스워드] -A

sqlcmd 설명 : https://docs.microsoft.com/ko-kr/previous-versions/sql/sql-server-2008-r2/ms162773(v=sql.105)?redirectedfrom=MSDN 

 

참고
https://sungwookkang.com/368

Delete 실행 시 확인창을 예제로 작성

modal 호출 시 매개변수를 포함하여 처리

 

html

매개변수 전달을 위해 modal_id를 hidden타입으로 생성

매개변수 전달을 위해 result.id 변수를 SetParamModal()함수에 전달

ID가 Delete_Modal 인 modal 생성

Close 버튼은 창 닫기

Delete 버튼은 Delete() 함수 호출

<!-- Button trigger modal -->
<input type="hidden" name="modal_id" id="modal_id">
<button type="button" class="btn btn-danger" data-toggle="modal" data-target="#Delete_Modal" onclick="SetParamModal('{{ result.id }}')">
  Delete
</button>


<!-- Modal -->
<div class="modal fade" id="Delete_Modal" tabindex="-1" role="dialog" aria-labelledby="DeleteModalLabel" aria-hidden="true">
  <div class="modal-dialog" role="document">
    <div class="modal-content">
      <div class="modal-header">
        <h5 class="modal-title" id="DeleteModalLabel">Delete</h5>
        <button type="button" class="close" data-dismiss="modal" aria-label="Close">
          <span aria-hidden="true">&times;</span>
        </button>
      </div>
      <div class="modal-body">
        삭제 하시겠습니까 ?
      </div>
      <div class="modal-footer">
        <button type="button" class="btn btn-secondary" data-dismiss="modal">Close</button>
        <button type="button" class="btn btn-primary" href="#" onclick="Delete()">Delete</button>
      </div>
    </div>
  </div>
</div>

js

SetParamModal(modal_id) : Modal 실행 시 매개변수 전달 기능

Delete() : 실제 삭제 로직 추가

<script src="./jquery-3.4.1.min.js"></script>
<script src="./bootstrapt/js/bootstrap.min.js"></script>
<link rel="stylesheet" href="./bootstrapt/css/bootstrap.min.css" />


// modal_id 타입에 전달받은 값을 설정
// Modal 버튼 클릭 시 호출
function SetParamModal(modal_id) {

    $('#modal_id').val(modal_id);
}


// Delete
// Modal창에서 'Delete' 버튼 클릭 시 호출
function Delete() {

    //Modal 호출시 전달한 id 확인
    id = $('#modal_id').val();
    
    // Delete 로직 실행
    // 'Delete from table where id = ' + id;
    
    // Delete modal창 닫기
    $('#Delete_Modal').modal('hide');
}

팝업 화면

참고

https://getbootstrap.com/docs/4.4/components/modal/

실행중인 프로세스가 갑자기 죽으며 Core 파일이 생성

Core 파일이 계속 생성되는 경우 Disk Full로 장애 발생

Core 파일 분석 후 이슈를 해소하여 시스템 안정성 확보 

Core 파일 생성을 위한 설정

1. ulimit -c unlimited
2. ulimit -a 로 확인
- 'core file size          (blocks, -c) unlimited' 면 설정 완료
- 만약 core file의 size를 제한하고 싶다면 'unlimited'가 아닌 kb단위의 size를 지정해주면 된다.

분석 방법

1. debug 대상 파일 확인

프로그램이 여러개가 돌고 있는 환경이라면 특정 dump가 어떤 프로그램이 만든것인지 확인 필요

file [core dump file]

* /proc/sys/kernel/core_pattern 에서 정의된 형태로 생성

   %p : pid

   %u : uid

   %g : gid

   %s : signal number

   %t : dump time(unix)

   %h : hostname

   %e : process

 

2. debugging

gdb [core발생 프로그램] [core file]

이후, gdb interface로 화면이 전환되면서 core에 관한 간략한 정보가 뜬다.
그리고 다음의 command를 입력하면 상세한 정보를 확인하는데 도움을 준다.

- bt(back trace) : core 발생 직전의 call stack 확인
- bt full : 전체 call stack 확인
- f[스택프레임 번호] : 특정 stack 확인
- list : stack의 code 보기
- info local : stack의 수행 당시 변수 값 확인
- info arg : stack의 argument 확인
- where : 간략화


의심되는 stack frame 분석

 info frame : 보다 상세한 정보 제공

 stack frame at 0x : 해당 함수 sp

 called by frame at 0x : 해당 함수를 호출한 함수의 SP(ex. main)

 Arglist at 0x : 해당 함수가 호출하는 함수의 bp

 args : 인자 정보

 saved registers : rip, ebp..

   (EX) (gdb) f [frame num] + (gdb) info frame

         (gdb) info frame [frame num]

 

해당 stack의 argument/local value 확인

 info frame 보다 간결하지만 인간친화적

 

  (EX) (gdb) info arg

        (gdb) info local

 

3. process debugging

gdb [프로세스명] [pid]

실행중인 프로세스를 gdb로 붙어서 확인

 

참고

https://incredible-larva.tistory.com/entry/core-dump-%EB%B6%84%EC%84%9D%EC%9D%84-%EC%9C%84%ED%95%9C-gdb-%EA%B0%84%EB%8B%A8-%EC%A0%95%EB%A6%AC

https://blog.naver.com/PostView.nhn?isHttpsRedirect=true&blogId=hymne&logNo=221841282483 

현상

threads 및 connection 증가

mysqldump FLUSH TABLES 지속

해결방안

* 고비용 쿼리 실행 시점과 backup 실행 시점을 겹치지 않도록 조정

* master 장비에서 백업이 실행되고 있다면, 이중화 구성 후 Slave 장비에서 백업 실행

* 고비용 쿼리 튜닝

* 장비 성능 점검 후 메모리 증설
* Flush method 변경 및 Swap 강제 해제

# /etc/my.cnf
innodb_flush_method = O_DIRECT
 
# shell
swapoff -a
swapon -a

* Kernel parameter 변경

# /etc/sysctl.conf
vm.swappiness = 60 -> 0
 
# shell
swapoff -a
swapon -a

FOUND_ROWS 적용 전

페이징 처리를 위해 limit 사용 시 전체 게시물의 수를 알기 위해 쿼리를 한번 더 해야 한다.

 

1. 해당 조건을 만족하는 게시물의 전체 수 조회
2. 그 페이지에서 보여줄 내용 조회

FOUND_ROWS 적용 후

SQL_CALC_FOUND_ROWS & FOUND_ROWS

 

SELECT 최상단에 SQL_CALC_FOUND_ROWS 라는 옵션만 주고 FOUND_ROWS() 를 사용하면 된다.

쿼리는 마찬가지로 두번이지만 두 번째 쿼리는 훨씬 빠르다.

mysql> SELECT SQL_CALC_FOUND_ROWS * FROM tbl_enchovy WHERE id < 100 LIMIT 10;
mysql> SELECT FOUND_ROWS();

첫번째 쿼리 검색 결과 : 10개

두번째 쿼리 카운트 값 : WHERE조건에 해당되는 Rows 카운트 ( 1~100사이에 누락된 번호가 없다면 99을 리턴 )

 

주의사항

1. SQL_CALC_FOUND_ROWS 키워드는 UNION의 첫 번째 SELECT에 나타나야 한다.
2. FOUND_ROWS()의 값은 UNION ALL을 사용하는 경우에만 정확합니다. ALL이 없는 UNION을 사용하면 중복 제거가 발생하고 FOUND_ROWS()의 값은 근사치만 된다.
3. UNION에 LIMIT가 없는 경우 SQL_CALC_FUND_ROWS는 무시되고 UNION을 처리하기 위해 생성된 임시 테이블의 행 수를 반환한다.

4. 복제시) FOUND_ROWS() 은 statement-based 형태로는 안정적으로 복제되지 않습니다, 이경우 row-based 형태로 자동 변경되어 복제가 됩니다.

 

※ MySQL 4.7.16 이전 버전에는 버그가 있어, 원하는 결과를 리턴하지 않음

* 5.7.16 이전 버전의 Query중 SybQuery가 있다면, SubQuery 내의 결과 Row 수를 FOUND_ROWS()로 Retrun
* 5.7.16 버그 픽스 이후는 전체쿼리문을 하나의 구문으로 보고 결과 ROW수를 FOUND_ROWS()로 return
  FOUND_ROWS() 함수의 기능은 이전 SELECT 된 쿼리의 ROWS를 RETURN 하는 함수(즉, 5.7버전의 기능이 정확)

    

FOUND_ROWS() 함수는 MySQL 8.0.17에서 더 이상 사용되지 않으며 향후 버전의 MySQL에서 제거될 것으로 예상된다..

참고

https://string.tistory.com/93

에러 로그

Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: ‘log event entry exceeded max_allowed_packet; Increase max_allowed_packet on master; the first event ‘binlog.000201’ at 5480571

분석

slave max_allowed_packet size (  1 M )

max_allowed_packet
서버에 전달 또는 서버로부터 받게 되는 패킷의 최대 길이
MySQL에서의 Packet이라 함은 Single SQL 문 또는 Replication이 이루어지는 Master에서 Slave로의 Binary Log Event를 의미한다.
MySQL 서버의 DEFAULT max_allowed_packet size 는 1 M 이다.

에러 로그는 master의 bin log packet이 허용할 수 있는 최대치를 초과했다는 에러 내용

해결 방법

mysql> set global max_allowed_packet = 1024*1024*100
mysql> set session max_allowed_packet = 1024*1024*100

재시작시 설정값 저장을 위해 my.cnf 파일도 함께 수정

현상

Windows Cluster 서비스 시작이 되지 않을때

에러 로그

The Cluster service cannot be started. An attempt to read configuration data from the Windows registry failed with error '2'. Please use the Failover Cluster Management snap-in to ensure that this machine is a member of a cluster. If you intend to add this machine to an existing cluster use the Add Node Wizard. Alternatively, if this machine has been configured as a member of a cluster, it will be necessary to restore the missing configuration data that is necessary for the Cluster Service to identify that it is a member of a cluster. Perform a System State Restore of this machine in order to restore the configuration data.

 Cluster Service 시작시 에러

해결

administration 권한으로 Cmd 오픈 후, 아래 명령어 실행하여 클러스터 초기화 진행

Cluster Node ServerName /ForceCleanup

아래 명령어로 클러스터 추가

Start-DatabaseAvailabilityGroup DAG1 -MailboxServer SiteA-Mbx1

해소되지 않는 경우 클러스터 신규 구성을 추천..

 

참고

http://www.lab365.in/2017/03/the-cluster-service-cannot-be-started.html

현상

MySQL 재시작 후 Table 내 AUTO_INCREMENT 값이 감소하는 현상이 발생

(예. 재시작 전: Auto_Increment 4000 , 재시작 후 Auto_Increment 3800)

원인

요약: MySQL InnoDB에서는 마지막 AUTO_INCREMENT을 메모리에만 저장

상세:

MySQL에서 InnoDB 엔진의 경우 AUTO_INCREMENT 값을 메모리에 저장하고 Insert 시 증가

 * 이슈 발생의 경우 tb_user 에서 data를 삭제 시 동일한 구조의 tb_user_del 값으로 insert 후 삭제하게 되는데

Table 의 AUTO_INCREMENT 값이 4000인 상태에서 SEQ가 3800~4000까지의 data를 tb_user_del 로 insert하고 삭제한 후 MySQL를 재시작하게 되면서 또 다시 SEQ가 3800부터 insert됨
(SEQ는 tb_user와 tb_user_del 모두 PK로 설정됨) 

재시작 이후 SEQ가 3800~4000인 data를 tb_user_del에 insert하면서 PK충돌이 일어나게 됨

해결 방법

AUTO_INCREMENT 를 MySQL 재시작시에도 유지하기 위해서는 엔진을 MyIsam으로 변경하거나 마지막 AUTO_INCREMENT값을 따로 기록을 하여야 함.

(발생한 이슈 해결을 위하여, tb_user_del의 PK를 nonclustered index로 변경하여 PK충돌을 해결하였음)

 


to Top