동일한 물리적 서버에서 복제를 실행하는 것이 현명하지 않습니까?

데이터베이스에 Master-Slave 복제를 설정하려고합니다. 슬레이브 서버는 리던던시 및 보고서 서버에 사용됩니다. 그러나 내가 겪고있는 가장 큰 문제 중 하나는 데이터 센터의 성능을 이미 최대한 활용하고 있다는 것입니다. 따라서 다른 물리적 서버를 추가하는 것은 옵션이 아닙니다.

기존 데이터베이스 서버는 CPU에 이르기까지 충분히 활용되지 않습니다 (부하 평균은 실제로 쿼드 코어에서 1을 초과하지 않습니다). 따라서 가장 새로운 아이디어는 일부 새로운 드라이브를 던져 메모리를 두 배로 늘리고 (8GB에서 16로) 동일한 실제 머신에서 두 번째 mysql 인스턴스를 실행하는 것입니다. 각 인스턴스에는 데이터베이스를위한 별도의 디스크가 있습니다.

이 아이디어에 문제가 있습니까?

편집 (자세한 정보) : 서버를 중단시킬만큼 나쁜 일이 없었지만 미리 계획하려고합니다. 물론 복구 할 수있는 야간 백업이 있습니다. 그러나 별도의 디스크에 중복 데이터를두면 마스터 서버의 드라이브에 장애가 발생했을 때 더 빠른 솔루션을 제공 할 것이라고 생각했습니다.

보고 측면에서 우리가보고 한 모든 테이블은 MyIsam입니다. 따라서 작성중인 동일한 테이블에서 값 비싼 읽기를 수행하면 서버가 다운 될 수 있습니다. 필자는 CPU 부하가 아직 문제가되지 않았기 때문에 RAM을 충분히 버린 경우 주 서버에 영향을 미치지 않는 슬레이브 서버가 있다고 가정했습니다.

마스터와 동일한 머신에서 슬레이브를 실행하는 시스템 안정성 및 데이터 안전성 측면에서 중복성을 위해 아무것도 제공하지 않습니다. 주인을 쓰러 뜨릴만큼 나쁜 일이 생길 경우 노예도 내릴 것입니다.

액세스 권한의 이유로 사용자를 순수하게 분리하기 위해 올바른 RDBMS는보다 효과적인 방법을 제공합니다.

동일한 머신에서 두 데이터베이스를 실행하면 두 데이터베이스가 다양한 버퍼와 캐시를 유지하기 위해 공간을 놓고 경쟁하기 때문에 동일한 효율성으로 실행하기 위해 더 많은 RAM이 필요합니다. 슬레이브의 데이터 파일이 마스터와 다른 물리적 드라이브에있는 경우 IO로드 분리를 통해 성능상의 이점이있을 수 있습니다. 이 경우 드라이브 IO 대역폭의 마스터와 경쟁하지 않고 슬레이브에 대해 많은 디스크 읽기가 필요한 복잡한 보고서를 실행할 수 있습니다.

편집 : DTest가 아래의 주석에서 언급했듯이 슬레이브 DB의 또 다른 이점은 마스터와 동일한 드라이브에 있더라도 슬레이브에서 복잡한 장기 실행 쿼리로 인해 일상적인 잠금 문제가 발생할 수 있다는 것입니다 마스터에서 매일 실행되는 쿼리가 더 안전합니다. 중요한 쿼리가 IO 경합 문제를 일으킬 가능성이 있으므로 다른 드라이브에 슬레이브를 두는 것이 여전히 낫습니다.

이것이 어떻게 문제를 해결하는지는 분명하지 않습니다. 동일한 물리적 하드웨어, 동일한 OS 커널, 동일한 MySQL 바이너리, 다른 디스크이지만 동일한 스토리지 컨트롤러 등에 있기 때문에 중복성이 없습니다.보고 DB의 이유는 OLTP DB에서 쿼리를 오프로드하는 것입니다. 모두 같은 키트에 있습니다. 추가 전원은 어디에서 오는가? 아니면이 설정에서 얻으려는 다른 것이 있습니까?

이것에 대한 한 가지 가능한 사용은 어쨌든 사용자를 분리하는 것이지만 다시는으로 할 수 있다고 생각했을 것입니다 GRANT.

그것은 실제로 현명하지 않은 것으로 간주됩니다. 더 많은 코어를 활용하려고합니까? 새로운 디자인 고려 사항의 목표는 무엇입니까?

(대화 스레드에 집중하기 위해 코멘트가 아닌 답변으로 게시 됨)

이것은 양날의 칼이 될 수 있습니다

각 MySQL 인스턴스가 다른 디스크에있는 경우 마스터와 동일한 서버에서 여러 개의 mysql 인스턴스를 읽기 전용 슬레이브로 실행할 수 있습니다. 다중 코어 (CPU)를 사용하지 않는 이전 버전의 MySQL을 실행하는 경우에만이 방법이 바람직합니다. 최신 버전의 MySQL은 실제로 여러 CPU를 사용하도록 조정하여 여러 MySQL 인스턴스를 실행하여 여러 코어에 액세스 할 필요가 없습니다.

동시에, 그것은 또한 매우 나쁜 생각입니다. 내 많은 고객들이 베어 메탈 또는 VM 서버 구매 비용을 절약하기 위해이 작업을 수행했습니다. 서버로드가 급증하면 하나의 MySQL 인스턴스에서 잘못된 쿼리, 느린 쿼리, 너무 많은 연결, 메모리 사용량 부족, 서버 메모리 부족, 캐시 스 래싱 등으로 인해 실행중인 모든 MySQL 인스턴스에 영향을 줄 수 있습니다. 또한 포트 번호를 통해 다른 MySQL 인스턴스에 액세스해야하므로 응용 프로그램의 복잡성을 증가 시키며 TCP / IP의 도움을받을 수 있습니다.

다른 서버, 즉 B의 A의 슬레이브와 A의 B의 슬레이브에서 복제를 수행하려고합니다. 우리는 서버에서 여러 인스턴스를 실행하며 MySQL 서버의 용량이 부족하여 문제가 없었습니다. 실행중인 서버로의 장애 조치는 백업에서 복원하는 것보다 훨씬 빠릅니다.