문제의 진정한 원인 찾기: 20121021 서버 장애 처리 경험

앞말
이 블로그에서 우리는 2012년 10월 21일 서버 고장 발생과 처리 과정을 공유할 것이다. 이것은 우리가 서버 운영에 존재하는 문제점을 반영하고 더 많은 비난과 우려를 불러일으킬 수 있다.그러나 우리는 진실한 힘을 믿고, 어려움을 이겨내겠다는 우리의 결심을 믿으며, 여러분의 이해와 지지를 믿습니다!처음에 블로그 정원을 만들었을 때 자신이 조립한 서버가 빈번했던 것을 생각하면 여러분의 이해와 지지와 도움으로 우리는 난관을 극복할 수 있었습니다.
본문
2012년 10월 21일 아침 8시에 일어나 양치질하고 세수하는 것처럼 습관적으로 첫 페이지(정상)를 열고 플래시 메모리를 켜면 눈에 보이는 것은 익숙한 페이지가 아니라 잘못된 페이지다. 가슴이 시리고 나쁜 하루가 시작된다.서버에서 오류 메시지는 다음과 같습니다.
Database 'CNBlogsUCenter' cannot be opened due to inaccessible files or insufficient memory or disk space. See the SQL Server errorlog for details.
땀!설마 데이터베이스 서버에 또 문제가 생긴 건 아니겠지?같은 일요일, 같은 8시, 설마 역사가 정말 재연되는 건 아니겠지?마음의 긴장을 억제하고 냉정을 유지하며 데이터베이스 서버에 올라가서 결말을 보자...
[일러스트] 왜 일요일 아침 8시에 나오냐고요?이 때 데이터베이스의 로그 백업 작업이 진행되기 때문에 로그 파일이 매우 크기 때문에 하드디스크의 읽기와 쓰기 부하가 매우 높다 (주: 이 작업은 비RAID5의 하드디스크에서 진행되며 데이터는 RAID5 하드디스크에 있다).
억지로 냉정+조심!서버에 올라가면 SQL Server Management Studio에서 데이터베이스 작업에 대한 오류 메시지가 표시됩니다.
The log for database 'tempdb' is not available. Check the event log for related error messages. Resolve any errors and restart the database. (Microsoft SQL Server, Error: 9001)
처음으로 이런 문제에 부딪혔는데,tempdb가 뜻밖에도 넘어갔다.비RAID5 하드디스크에 저장된tempdb 데이터베이스 파일을 보십시오. (당초 성능을 고려하여tempdb 데이터베이스 파일을 비RAID5의 독립 하드디스크에 놓았습니다.) 파일이 존재했지만 갑자기 이 하드디스크에 다른 폴더가 많이 보이지 않는 것을 발견했습니다.RAID5가 아닌 이 독립형 하드 드라이브에 문제가 생긴 것 같습니다.당시 우리가 생각한 해결 방안은tempdb를 RAID5의 하드디스크로 전환하는 것이다.
[작은 지식] 만약tempdb 데이터베이스 파일이 손상되거나 분실되면 SQL Server는 어떻게 처리합니까?데이터베이스 파일의 경로에 접근할 수 있다면 (하드디스크가 고장나지 않거나 새 하드디스크를 바꾸고 같은 경로의 폴더를 만들었을 때) SQL Server는 자동으로 tempdb를 재구성합니다.그러나 현재 하드디스크에 문제가 생겼습니다. SQL Server는tempdb를 재건하려고 해도 현재 파일 경로를 사용하여tempdb 데이터베이스 파일을 새로 만들 수 없습니다.SQL Server는 디자인에서도 이 문제에 대해 용착을 고려하지 않았습니다. 예를 들어 tempdb 재건에 실패했을 때 기본 경로를 사용하여 다시 재건합니다.
이어서 다음 코드로 tempdb 전환 작업을 진행합니다.

use master

go

Alter database tempdb modify file (name = tempdev, filename = 'D:\TempDb\tempdb.mdf')

go

Alter database tempdb modify file (name = templog, filename = 'D:\TempDb\templog.ldf')

Go

그러나 답답한 것은 조작이 실패했다는 것이다. 당시의 오류 정보를 보면tempdb를 전환할 때 SQL Sever는 원래의 tempdb 파일을 읽어야 한다(SQL Server가 이곳에 있는 디자인이 불합리하다고 느낀다).
우리는 짧은 시간 내에 다른 Tempdb를 전환하는 방법을 찾지 못하고 SQL Server 서비스를 다시 시작했지만 시작할 수 없었다.
시간이 촉박하기 때문에 우리는 두 번째 복구 방안을 시작하여 데이터베이스 파일을 다른 서버로 복사하여 복구했다.단, 로그 파일 (.ldf) 이 문제가 발생한 하드디스크에 저장되어 있기 때문에, 로그 파일은 복사할 수 없고, 통과할 수 밖에 없습니다.mdf 파일을 복구합니다. 복구 방법은 상세합니다데이터베이스 로그 파일이 손상된 상황에서 데이터베이스를 복구하는 방법.주요 작업 단계는 다음과 같습니다.

같은 이름의 데이터베이스를 새로 만듭니다.

데이터베이스 서비스를 중지합니다.

용.mdf 파일은 새 데이터베이스의 동명 파일을 덮어씁니다.

데이터베이스 서비스를 시작합니다.

alterdatabasedbname set emergency를 실행하고 데이터베이스를emergency mode

로 설정합니다

일부 명령을 실행하여 복구

이전에 우리는 같은 서버에서 이러한 복구를 테스트한 적이 있지만, 다른 서버에서의 복구를 테스트한 적이 없다.이번에는 다른 서버에서 복구가 성공하지 못하고 오류가 발생했습니다.
One or more files do not match the primary file of the database. If you are attempting to attach a database, retry the operation with the correct files. If this is an existing database, the file may be corrupted and should be restored from a backup.
몇 차례의 시도를 거쳐 이 문제를 해결하지 못했다.시간도 우리가 이 문제에 계속 소모하는 것을 허락하지 않는다. 우리는 기계실에 가서 비RAID5 하드디스크 문제를 처리해야 한다.
기계실에 가기 전에, 우리는 데이터베이스 서버를 다시 시작해서 켜지 못했다.그리고 기관실로 달려갔어요.
...
기계실에 가서 모니터를 연결해 보니 지난번 고장과 같은 오류 정보:
Foreign configuration(s) found on adapter Press any key to continue or 'C' load the configuration utility, or 'F' to import foreign configuration(s) and continue.
There are offline or missing Virtual drives with preserved cache. Please check the cables and ensure that all drives are present. Press any key to enter the configuration utility.
이번에 우리는 왜 이 잘못된 정보가 발생했는지 이미 똑똑히 알고 있다.
데이터베이스 서버는 Dell PowerEdge R710을 사용합니다. RAID5가 아닌 독립 실행형 하드 드라이브는 RAID0 방식으로 가상 디스크를 구성합니다(이렇게 해야 함). 이 하드 드라이브에 문제가 발생하면 RAID 카드는 가상 디스크가 고장 났다고 생각하고 처리해야 기계를 시작할 수 있습니다.
해결 방법은 두 가지가 있습니다.
1. RAID 카드의 configuratin utility에 들어가서preserved cache를 제거합니다. 즉, 이 가상 디스크 정보를 제거하고 RAID5의 가상 디스크만 보존하여 기계를 작동시키는 것이 임시 해결 방법입니다.
2. 새 하드 드라이브를 교체하고 RAID0으로 가상 디스크를 다시 생성합니다.
만약tempdb 때문이 아니라면 (이전에 tempdb가 문제가 발생한 하드디스크에 있고 RAID5 하드디스크로 전환되지 않는다고 말했듯이), 우리는 첫 번째 해결 방법을 채택하여 서버가 가능한 한 빨리 운행을 회복할 수 있다.이제 첫 번째 방법으로 서버를 시작하지만 SQL Server는 시작할 수 없습니다.그래서 우리는 두 번째 방법으로 새 하드디스크를 교체한 다음에 새 하드디스크에tempdb 데이터 파일을 저장하는 같은 이름의 폴더를 만들고 SQL Server에서tempdb를 재건할 수 있습니다.
그래서 우리는 Dell에 전화를 걸어 엔지니어를 배치해서 하드디스크를 교체하도록 했습니다.Dell에서 구입한 Dell 서비스는 당일 4시간 이내 방문 서비스로 지난 2시간 이내에 방문할 수 있었으나 이번에 4시간 가까이 방문하여 Dell 엔지니어를 기다리는 데 많은 시간을 소비했습니다.
Dell 엔지니어가 와서 하드디스크를 교체하고 가상 디스크를 만들면 서버가 정상적으로 시작됩니다.그리고 우리는 원래 하드디스크와 같은 구역을 만들고 같은 이름의tempdb 데이터베이스 파일을 저장하는 폴더를 만들었습니다.SQL Server 시작, tempdb 자동 재구성, SQL Server 정상 시작.
그러나 이때 의외의 상황이 발생하여 데이터베이스 로그 파일 (.ldf) 이 자동으로 재구성되지 않았다.이전에 우리는 테스트를 한 적이 있다.mdf 파일이 존재하고 로그 파일(.ldf)이 존재하지 않을 때 SQL Server가 시작되면 자동으로 재구성됩니다.이번에는 데이터베이스 로그 파일을 저장하는 폴더가 존재하지 않아서 SQL Server 재구성 로그가 실패했기 때문일 수도 있습니다. (추측일 뿐, 확인되지 않았습니다.) 그 후에 저는 해당하는 폴더를 만들어 보았지만 문제를 해결하지 못했습니다.
이어서 우리는 두 번째 방안으로 데이터베이스 복구에 성공했다(시나리오 소스. 구체적인 조작은 다음과 같다.
1.alter database database set emergency를 실행하고 데이터베이스를 emergency mode로 설정
2. 다음 명령을 실행하여 복구합니다.

use master 



declare @databasename varchar(255) 



set @databasename=' ' 



exec sp_dboption @databasename, N'single', N'true' --  



dbcc checkdb(@databasename,REPAIR_ALLOW_DATA_LOSS) 



dbcc checkdb(@databasename,REPAIR_REBUILD) 



exec sp_dboption @databasename, N'single', N'false'--  

이 복구는 데이터베이스별로 조작해야 할 뿐만 아니라 다른 데이터베이스 접근 조작이 없는 상황에서 조작하는 데 시간이 많이 걸리고 데이터 양이 가장 많은 데이터베이스가 있어 복구하는 데 십여 분이 걸린다.
결어
위에서 공유한 것은 서버 고장 발생과 처리 과정입니다. 8시경에 고장이 났고 20시경에 복구까지 12시간 정도의 시간이 걸렸습니다. 여러분께 정말 죄송합니다!문제는 RAID가 아닌 하드 드라이브로 인해 발생했습니다. 더 죄송합니다!
일방적으로 한 문제를 보면 간단하게 해결할 수 있을 것 같다.그러나 복잡하고 변화가 많은 현실 상황에서 당신 앞에 문제가 산더미처럼 쌓여 있어 모든 문제가 그리 간단하지 않다.
오직 그 안에 있어야만 너는 그 속의 어려움을 진정으로 느낄 수 있다.오직 그 안에 있어야만 너는 어려움을 이겨내는 그 흥분을 진정으로 느낄 수 있다.그 안에 있어야만 너는 어떤 문제도 문제가 아니라고 믿을 수 있다. 네가 진지하게 직면하기만 하면!
우리는 이 문제를 근본적으로 해결하는 방법을 알고 있습니다. 우리는 실행에 옮기고 그 과정을 여러분과 공유하고 있습니다!
"창업하러 나왔는데 당신이 찾고 있는 것은'성공'이 아닙니다. 당신이 찾고 있는 것은'진보'-Jamie"입니다. 우리는 우리의 진보로 블로그원 팀이 성장하고 있음을 알려야 합니다!