경험 공유: Ganji.com의 3년 DBA 요약

저는 2013년 초에 공지에 합류했습니다. 당시 저는 트래픽이 급속히 성장하는 단계에 있었습니다. 3년 간의 DBA 경력 동안 많은 것을 얻었지만 사실 더 많은 함정이 있었습니다(눈물... 나중에.) , 개발을 하면서 점차적으로 "운영 및 유지 관리"를 깨달았고 "개발"에는 실제로 의사소통 문제가 있습니다. 이를 해결하는 방법은 무엇입니까? 지난 3년간의 변화를 요약해 보겠습니다. , 공통점을 즉시 찾을 수 있습니다.

데이터베이스 시스템의 계획, 설계, 관리 및 마이그레이션데이터베이스의 일일 유지 관리, 백업, 최적화 및 복구

마스터-슬레이브 아키텍처 구축 및 유지 관리

비즈니스 시스템 온라인 지원, 데이터베이스 설계 검토, 아키텍처 솔루션 제공

데이터베이스는 MySQL, Oracle에 국한되지 않고, 세부적으로 나누어지지 않으면 Redis, MongoDB도 있을 것입니다. 그리고 일련의 NoSQL 작업 내용은 동일합니다. 첫 번째는 높은 가용성과 안정성이며 두 번째는 백업 및 복구와 같은 많은 작업이 필요합니다. - 연간 시장 감사 및 모바일 단말의 활성 사용자 백업에서 데이터가 복원됨은 물론 백업의 효율성이 최우선임을 알 수 있습니다. 사생활에 방해가 된다고 해서 파업을 할 수는 없어요. 영화를 보다가 다시 전화를 받았는데, DB 알람을 처리하러 가면 어머니를 혼내고 싶은 마음이 듭니다. 비극적인 사건

심판님들을 기쁘게 해줄 비극적인 사건을 알려드리겠습니다~ 회사가 없어진지 오래되니까 걱정하지 마세요.

1. table

WHERE 조건 없이 SQL을 틀리게 쓴 것은 중고차 동창의 잘못이고, 오프라인 스크립트 작성 시 오류가 발생했습니다...드디어 DBA가 기반으로 복원하였습니다. 행 binlog에서 2번 이상:(

반성: rd 초보자가 연달아 오고 사양이 아무리 많아도 쓸모가 없습니다. 가장 완벽한 솔루션은 하나뿐입니다. 프록시에 연결하는 것입니다. , 불법 sql 모두 제한합니다. 게다가 3차 온라인 검증도 안되어 있고, 코드리뷰에서 빠진 부분이 있을 것 같습니다

2. 빅셀러의 문제점

부동산은 2014년에 자유항을 열었습니다. 불과 몇 달 만에 부동산 사업 테이블이 100G로 폭발했고, 일부 중개 계정에서 10W가 넘는 금액이 게시되어 비정상적인 데이터베이스 지터가 일시적으로 발생했습니다. 마침내 3개월을 들여 테이블을 줄였습니다.

반성: DBA의 대규모 테이블 모니터링 부족

3.

주요 사이트 소유자 한때 서브 쿼리로 인해 라이브러리가 차단된 적이 있었습니다. 조사 결과 이러한 문제는 RD에 많은 서브 쿼리를 작성했기 때문에 발생하는 것으로 나타났습니다. 슬레이브를 읽어야 할 마스터에게 요청했지만 사고가 발생하지 않았습니다.

반성: Ganji DB 일반적인 1 마스터 N 슬레이브, 프록시 보호가 없으면 표준으로 해결할 수 없는 이러한 문제가 자주 발생합니다. 시스템 단독

4. olap 라이브러리 문제 신고

RP Kuwo와 Wenwu가 책임을 맡아 연말 실적이 최하위를 기록했습니다. Wenwu가 인수하기 전의 RD는 중개 가맹점 보고 시스템을 직접 개발했으며, 모든 계산은 DB를 기반으로 했습니다. 무료 포트가 열렸을 때 MyISAM 읽기-쓰기 잠금으로 인해 많은 요청이 차단되었습니다. 지속적인 신고 문제로 인해 회사에서 가맹점에게 300W를 보상했다고 들었습니다.

반성: 이번 사고는 자유항이 너무 갑자기 열려서 프로젝트 기술 리더가 테스트를 완료하지 못한 상황에서 봐야 한다. 보고 시스템은 설계되지 않았으며 대학 졸업자에 불과한 새로운 RD에 의해 완전히 처리됩니다. 되돌아보면 Hadoop Spark가 이를 완벽하게 처리할 수 있습니다. 결국 DBA는 대형 테이블을 제때 추적하지 못하고, 사전에 발견하지 못했다.

5.50G Redis

부동산 사업 Redis가 20G에서 50G로 폭발했는데 제가 떠난 이후로 최적화가 안 됐어요. 나중에 오류가 나서 데이터가 지워졌나요?

내 작업

저는 대부분의 시간을 개발자들과 소통하고 인생에 대해 이야기하는 데 보냅니다. 무대에 가면 고마운 사람, 사물이 있어요. 시장에 가면 제가 관심 있는 일을 할 수 있는 기회가 생기거든요. 정말 행복해요.

2014년 중반 Automan 플랫폼 개발을 시작하여 프론트엔드 페이지부터 백엔드 메시지 큐, SQL 파서 분석까지 처음부터 끝까지 친구의 도움으로 온라인으로 완료했습니다. Liu Jun Xianhe. 플랫폼은 개발된 SQL을 검토하고 시뮬레이션 환경을 거친 후 자동으로 온라인 백업을 수행하므로 수작업보다 훨씬 효율적이다.

이 시스템의 원리는 시중의 다른 도구와 유사하지만 몇 가지 주요 개선 사항이 있습니다. 나중에 데이터베이스 컨퍼런스에서 한 번 공유했는데 비난을받지 않을까 두려웠습니다.

DBA 경험

기초를 공고히 하다: DB의 기초는 자연스럽게 안정되고, 안정되고, 그러다가 안정됩니다. 인스턴스가 너무 많으면 기본적으로 매일 다양한 장애가 발생하게 됩니다. 마스터에 오류가 발생하면 MHA 스위칭을 사용하세요(최신에는 gtid가 있음). 슬레이브에 오류가 발생하면 lvs는 자동으로 읽기 트래픽을 제거합니다. 또 다른 하나는 백업, 전체 증분, 정기 백업 유효성 테스트이며 각 부분에는 인적 투자가 필요합니다.

하드웨어 우선순위: DB 용량을 확장하는 방법에는 Scale Up과 Scale Out 두 가지가 있습니다. 일반적으로 하드웨어에 우선순위가 부여됩니다. 버퍼가 부족하면 메모리를 추가하세요. 128G가 부족하면 192G를 사용하세요. 디스크 어레이 카드의 성능이 좋지 않으면 SSD를 사용하세요. 즉, 필터 하드웨어 테스트에 우선순위를 두고 아키텍처 최적화를 위한 시간을 확보하십시오.

비 오는 날에 대비하세요: 느린 SQL을 최적화하고 정기적으로 RD를 위한 보고서를 발행합니다. 일반적으로 문제는 대규모 SQL의 99%가 이렇습니다. 이는 불합리한 테이블 디자인(자동 증가 없음) 기본 키 또는 자주 수정되기 때문입니다. 대규모 테이블 모니터링, 필요한 경우 축소, 필요한 경우 수평 및 수직으로 필드 분할, 만료된 데이터를 정기적으로 보관하는 것이 기본적으로 전부입니다.

비즈니스와의 통합: 일부 최적화는 DBA를 지치게 만들기 때문에 RD가 코드 한 줄을 수정하는 것이 더 좋습니다. DBA는 또한 비즈니스와 더 많은 접촉을 갖고 비즈니스 구현을 이해해야 하며 비즈니스에 많은 기여를 할 필요도 없고 비난을 받을 필요도 없습니다... 농담입니다. 비즈니스를 이해하면 더 높은 관점에서 생각할 수 있다는 것은 매우 의미 있는 일입니다.

아니요라고 말하는 법을 배우십시오. 이 거부는 파업을 하고 일을 하지 않는 것이 아니라, 불합리하고 긴급하지 않은 요구 사항을 구별하여 직접 처리할 수 있는 것입니다. 긴급하지만 불합리한 문제는 일시적으로 통과하고 나중에 문제를 신속하게 해결할 수 있습니다. 예를 들어, olap은 온라인 라이브러리에서 실행되고, count(*) 계산 SQL은 카운터를 비동기적으로 실행할 수 있으며 Redis는 좋은 것입니다.

의사소통하는 법을 배우십시오. 저는 몇 년 동안 일해 왔지만 아직도 배우고 있으며 많은 실수를 저질렀습니다. 권리와 책임을 전달하고 시간표를 정합니다.

실전 학습: 돌이켜보면 그 당시에는 DBA가 제대로 된 성과를 내지 못한 이유도 개발 역량이 부족했기 때문이었고, 많은 아이디어가 거기에서 멈췄습니다. 운영 및 유지보수 인력은 운영 및 유지보수 업무를 잘 수행하기 위해서는 사업 RD보다 개발 능력이 뛰어나고 정교해야 합니다.

RD 운영 및 유지 관리의 모순과 모순

KPI도 다르고 초점도 당연히 다릅니다. 일선 학생들도 경험이 부족합니다. 특히, 이제 막 일을 시작한 지 1~2년이 되어 정보와 지식의 비대칭이 발생하고 있습니다. 이 문제를 해결하는 것은 어렵지 않습니다.

신입생을 멘토의 지도를 받아야 합니다. 그들을 내버려 두는 것은 가장 무책임한 일입니다. 이런 면에서 좋은 일을 했다는 생각이 듭니다. 그래도 칭찬받을 자격이 있을 때는 칭찬해야 합니다.

지원팀은 충분한 Wiki 비즈니스 문서를 보유해야 합니다.

자동화는 육체 노동이 아닌 기술의 제약을 받습니다. 비즈니스 인터페이스는 이전보다 더 제한적이며 이제 서비스 기반 서비스는 모두 절약을 사용합니다.

시장에 나갔던 기억이 점점 흐릿해졌는데...

요약 일부를 쓰다가 예전 동료들이 놓친 게 있다고 해서 다 첨부하겠습니다. , 저작권은 저에게 없습니다 :)

20170214 다음 내용은 이전 동료의 내용입니다: Li Rui

DBA에 대한 추억 시장에서의 삶

결론적으로, 언제든지 처리해야 할 문제가 많이 있습니다. 오토맨이 나와서 강제로 온라인에 접속할 때까지는 조금 나아질 것입니다. 플랫폼을 통해.

raid0 문제로 인해 마스터하드에 최소 4~5번 이상 문제가 발생하여 긴급치료가 필요했습니다.

tg에서 한 번 발생했는데, ms 컷 시간이 발생했는데, 디스크 문제인 것 같습니다.

다른 슬레이브 백업 머신은 하드 드라이브 오류가 더 많고 일주일에 최대 4개의 디스크 문제를 처리해야 합니다. Ganji의 mysqldb는 일반적으로 최소 100G 크기이며, 데이터 리포트 데이터베이스의 디스크는 2.3T입니다. 백업을 통해 슬레이브 데이터베이스를 복원하는 것은 불가능합니다

im Swap 문제

Im 스왑 문제는 확실히 SQL 문제입니다. 주요 SQL 쿼리는 order by와 count를 통해 데이터를 얻는 것입니다. 이 문제는 제가 처음부터 해결하지 못했습니다. 나올 때쯤 시장에 들어갔다. 스왑 문제를 해결하는 유일한 방법은 트래픽을 수동으로 LVS로 전환하고 슬레이브를 다시 시작한 다음 트래픽을 다시 LVS로 전환하는 것입니다. 거의 일주일에 1~2번 정도가 필요합니다. 카운트 쿼리에 대한 카운터를 만들려고 IM 동료들에게 IM SQL 문제에 대해 여러 번 말했지만 결국 아무 일도 일어나지 않았습니다. 서버가 자주 oom될까 봐 스왑을 끄십시오. 마지막으로 동급생 Zhao Shenju가 온 후 innodb_buffer_pool 예열 매개 변수를 켠 후 예열 문제로 인한 갑작스러운 부하 증가에 대한 두려움 없이 슬레이브를 직접 다시 시작할 수 있습니다. 다른 동급생 자오신주는 누마 제한 메모리를 변경했지만, 임스왑은 결국 해결되지 않았다.

백업

백업 문제, 1은 디스크 공간 문제, 1은 raid0 문제입니다. .

당신이 떠난 후, 비창기가 올 때까지 한 달 동안은 백업머신이 6~7개 있었는데, 하드디스크가 연달아 고장나더군요. 로그 라이브러리, emp 및 Wang Xufeng 그룹, 비즈니스 라인 이름을 잊어 버렸고 데이터가 800G로 증가했으며 백업 시스템이 손상되어 공간이 부족했습니다. 나는 단순히 백업을 중지하고 마침내 ms, hp, tg, tc와 같은 일부 대규모 데이터베이스의 백업만 보장했습니다. 이 58세 동료는 아마도 인수 후 그들로부터 경멸을 받을 것입니다.

사실 화웨이의 32T 백업 머신이 나온 후에는 백업 메커니즘을 바꿔야 합니다.

2개월마다 4개의 2T 디스크가 가득 찼습니다. , 디스크 교체, 이동, RAID 디스크 수동 마운트 및 Excel에 수동으로 기록합니다. 결국 이 디스크들은 실제로 데이터 검색에 사용됐다.

디스크 문제

Hp에는 두 개의 큰 테이블이 있으며 데이터를 정기적으로 정리해야 합니다. Ms 디스크는 하루 10G의 속도로 증가하며 Ms에는 pcie 카드가 필요합니다. 마지막으로 800에서 1200까지 확장할 수 있습니다. 몇 달 동안 지속될 수 있습니다. Ms.는 여러 대의 기계를 가지고 있는데, 결국에는 가득 차기까지 약 10G 정도 부족합니다. 모든 종류의 로그 삭제, 모든 종류의 데이터 이동 및 동쪽 벽 보충. (xfs와 함께 400G SSD를 사용하면 ext4에 비해 20G의 공간을 절약할 수 있으며 이는 ms에 충분합니다.) 디스크가 커지고, 백업 머신의 디스크 공간이 부족하고, SIM 머신(개발용 읽기 전용 서비스를 제공하는데, 이름이 무엇인지 잊어버렸습니다)의 공간이 부족합니다. 보고서 라이브러리도 있는데 디스크와 서버를 신청하고 싶은데 캐비닛에 공간이 없어서 오랫동안 라이브러리 하나로만 운영했습니다.

또한 프레임워크를 통해 Wang Xufeng 그룹과 TC가 생성한 SQL

varchar 유형의 필드 조건은 작은따옴표를 추가하지 않으며 온라인 테이블 생성도 추가합니다. 인덱스를 추가하지 않으면 SQL을 정기적으로 확인하고 최적화해야 합니다.

아픈 HP, 메인 라이브러리 분할.

1년이 넘게 걸렸지만 완전히 분리되지는 않았습니다. 마지막으로 나는 Bi Changqi로부터 Guazi 중고차가 이 창고에서 분리되었다는 소식을 들었습니다. 하향식, 강제 분할. 1~2일에 나누어서.

PHP 짧은 연결, 연결 수가 꽉 찼습니다

이 마지막은 당신이 떠난 후 가끔 hp 전체 로그를 분석하여 1-마다 hp가 있음을 발견했습니다. 2회 연결, 빈 연결이 동반됩니다. Connect는 아무것도 종료하지 않습니다. 이 문제의 원인을 모르겠습니다. 수정 후 HP 연결 수 문제가 해결되었습니다.

요약하자면 간지에서는 폭증하는 데이터 때문에 무작정 대응만 하고 빨리 매듭을 끊지 못하고 스핀오프를 진행하게 되었습니다. 게다가 모니터링을 관리하고 검토를 위해 SQL을 제출하는 DBA 플랫폼도 꼭 필요한데, 나중에서야 마지 못해 Automan을 흉내내서 작성할 수 있게 되었습니다.

이 기사는 PHP 중국어 웹사이트의 네티즌인 Zerun이 기고한 것입니다. 이 기사의 주소는 http://www.php.cn/toutiao-352102.html입니다.