뷁키백과는 데이터베이스 엔진으로 미디어위키를 쓴다. 그런데, 뷁키백과 데이터베이스를 흔드는 과정에서 미디어위키 데이터베이스에 너무 많은 글이 들어가서 글 개수 통계가 섞이는 등 만행이 일어났기 때문에 이런 특단의 조치로 전체 리비전을 지웠다.

1. 우선 리비전을 지울 글을 클릭해서 “편집”을 누른다.
2. 그 다음, 명령줄에서 "php -cli nukePages.php [페이지_제목]"을 입력한다.
3. 다 되면 저장을 누른다.

그런데 이 과정에서 ㅅㄱㅎ 문서가 제대로 복구되지 않아서 옛 버전으로 남아있었다는 것을 망각했던 채

이 명령을… 때렸다! 처참한 결과만 남아서 울고 있었다. 위키백과의 특정 버전 삭제와는 다르게 이 명령은 데이터베이스 자체적으로 모든 것을 지우기 때문에, undo가 가능한 특정 버전 삭제와는 달리 동작은 한 방향이다. 이럴 때 쓸 수 있는 말이 OTL이지.
그러나 하늘이 무너져도 희망은 있는 법. 윈도우 서버 RWAPM이라는 것이 떠올라서 그 녀석을 통해서 전에 받아 두었던 DB 전체 백업을 다시 올렸다. 그리고 phpMyAdmin으로 들어가서 페이지를 찾아야 했다. 그렇지만 미디어위키의 너무 철저한 리비전 때문에 한 문서를 가르키는 테이블이 총 3종류 있다. 그 셋은 [prefix]_page, _text, _revision이다. 이제 이 세 테이블을 따라가 보자. [prefix] 값은 적절한 것을 찾으면 되고 여기서는 brw_이다.
우선, brw_page 테이블에서 page_title을 기준으로 ㅅㄱㅎ를 검색한다. 그러면 그에 대응하는 page_id와 page_latest 값을 찾을 수 있다. page_id 값과 page_latest 값을 기억한 다음, brw_revision에서 rev_id 기준으로 아까 찾은 값을 대입해서 검색한다. 그러면 rev_page 값과 page_id 값이 같으면 빙고라는 뜻을 이야기한다. 그 다음 brw_text로 간다.
그런데 이 녀석이 BLOB으로 기록되어 있다? 그래서 phpMyAdmin은 보여 주기를 거부하고 있다. 그것 때문에 MySQL을 직접 건드려도 봤으나 별 소득이 없었다. 그러다가 내 눈에 들어온 것이…

였다! 즉, CSV 파일로 내보낸 다음에 검색하면 된다는 뜻이다. 이것을 몰라서 오늘 오전 내내 허공에다가 삽질하고 있었다. CSV 파일에서 검색은 page_latest 값을 기준으로 검색하면 내용이 나온다. 그러나, 다행히도 내용의 일부를 기억하고 있기 때문에 그것을 기준으로 검색을 해서 결국 문서를 살렸다.
오늘의 결론.

• 백업과 복원을 생활화하자.
• 무엇이든지 원리와 구조를 알고 논리적으로 접근하자.
• 경희누나 미안.