기업 환경에서는 다운타임으로 인한 비용이 빠르게 증가합니다. 한 설문조사에서 응답자의 40%는 단 한 시간의 다운타임으로 인해 조직에 100만 달러 이상의 손실이 발생했다고 말했습니다. 데이터베이스 서비스를 지속적으로 사용할 수 있도록 하는 것은 분명히 가치 있는 일입니다. 모든 형태와 규모의 이해관계자와의 관계는 말할 것도 없고 조직의 엄청난 비용을 절약해 줍니다.
그렇다면 지속적인 가용성을 어떻게 보장할 수 있을까요? 지속적인 가용성의 기본 개념을
고가용성이라고 합니다. 이 문서에서는 고가용성이 무엇인지, 그리고 이를 MySQL 클러스터에 구현하는 방법에 대한 개요를 제공합니다. 또한 시스템 관리자가 실수로 고가용성에 의존하여 유지 관리 작업을 수행하는 경우에도 고가용성의 어두운 면을 지적하고 그렇게 하면 고가용성 목표가 달성되지 않고 비즈니스 운영이 위험에 빠지는 이유를 설명합니다.
1. 고가용성 소개
먼저 가용성에 대해 이야기해 보겠습니다. 사용자가 대부분의 시간 동안 사용할 수 없는 서비스(예: 데이터베이스)를 실행하는 것은 거의 의미가 없습니다. 따라서 가용성에 관해 이야기할 때는 서비스에 얼마나 접근할 수 있는지를 의미합니다.제대로 실행되는 서비스는 필요할 때 항상 사용할 수 있다고 합리적으로 예상할 수 있습니다. 그러나 1년에 하루나 이틀 또는 한 달에 몇 시간 정도의 가동 중지 시간도 있을 수 있습니다.
일반적으로 사용 가능한 서비스는 다양한 사용 사례 시나리오에 적합할 수 있지만 서비스가 본질적으로 중요하거나 다수의 사용자가 서비스에 의존하는 경우 "가용성"에만 의존하는 것만으로는 충분하지 않습니다.
이것이 바로 고가용성입니다. 가장 기본적으로 고가용성은 일반적으로 예상되는 것보다 더 높은 수준의 가용성을 보장하며, 더 구체적으로 합의된 수준을 보장하여 유지 관리, 패치 적용, 일반적인 오류 및 실패를 허용합니다.
2. 고가용성은 어떤 수준의 가용성인가요?
고가용성이 무엇인지에 대해 합의된 정의는 없습니다. 이는 단지 특정(더 높은) 가용성 요구 사항을 충족하는 것에 관한 것입니다. 이는 일반적으로 공급자가 "가용성"으로 허용하는 수준을 초과합니다. 실제로 조직에서는 가동 중지 시간 관련 손실 비용과 고가용성 비용을 비교하여 운영 요구 사항에 따라 필요한 가용성을 정의할 수 있습니다.필요한 가용성 수준은 백분율로 표시될 수 있습니다. 예를 들어, 99.99% 또는 "4 나인" 가용성은 연간 최대 52.06분의 가동 중지 시간을 의미하는 반면, "6 나인" 또는 99.9999% 가용성은 연간 가동 중지 시간을 31.56분으로 제한합니다.
기본적으로 선택은 귀하의 몫이지만, 다시 말하지만 이는 절충점입니다. 고가용성을 유지하려면 추가 물리적 리소스와 소프트웨어 라이센스가 필요하고 인적 자원이 고갈되므로 비용이 많이 듭니다. 그러나 중단으로 인한 추가 비용이나 고객 불만으로 인한 수익 손실 위험을 피하기 위해 지불할 가치가 있는 대가라는 것을 알 수 있습니다.
3. 고가용성은 실제로 어떻게 작동하나요?
고가용성 인프라의 정확한 특성은 워크로드에 따라 다릅니다. 그러나 광범위하게 말하면 하나의 서비스나 장치에 장애가 발생하더라도 작업 부하가 중단되지 않도록 내결함성이 있어야 고가용성이 달성됩니다. 일반적으로 이는 단일 장애 지점이 없음을 의미합니다. 모든 서비스와 장치는 네트워크 및 애플리케이션 수준에서 완전히 중복됩니다.서비스에 따라 여기에는 일반적으로 여러 개의 노드가 포함될 수 있습니다. 예를 들어 MySQL 클러스터에는 데이터가 저장되는 몇 개의 노드가 더 포함됩니다. 그러면 여러 노드가 로드 밸런싱 도구와 결합되어 한 노드에 장애가 발생하면 요청이 다른 노드로 전달됩니다. 성능이 약간 저하되더라도 사용자는 계속해서 사용 가능한 서비스에 액세스할 수 있습니다.
4. MySQL에서 고가용성 구성
물론, 고가용성 MySQL 데이터베이스로의 경로는 MySQL 구현에 따라 달라집니다. 간단히 말해서, 여러 노드가 있는 특정 유형의 MySQL 클러스터를 생성해야 합니다. 즉, 데이터가 여러 MySQL 서버에 저장되어야 합니다.다음으로, 이러한 노드에 데이터를 복제하여 각 노드가 데이터베이스에 포함된 데이터의 정확한 복사본을 갖도록 보장할 수 있는 서비스가 필요합니다. 마지막으로, 모든 데이터베이스 요청이 데이터베이스 노드에 고르게 전달되도록 하려면 로드 밸런서가 필요합니다. 즉, 로드 균형이 조정됩니다. 하지만 한 노드가 오프라인이 되더라도 요청이 충족되는지 확인해야 합니다.
예를 들어 MySQL은 고가용성을 위한 상용 제품인
Te MySQL InnoDB Cluster를 제공합니다. 이는 MySQL 데이터베이스 환경에서 고가용성을 보장하는 널리 사용되는 방법인 MySQL 그룹 복제를 기반으로 합니다. 또 다른 대안은 수년간 MySQL 고가용성을 제공해 온 Galera입니다. MySQL의 MariaDB 포크를 사용하는 경우 로드 밸런싱을 위해 HAProxy를 사용하는 동시에 Galera 클러스터에서 여러 노드를 실행하여 고가용성을 위해 MariaDB 환경을 구성할 수 있습니다. 또는 MariaDB의 자체 MaxScale 6. 그리고 고가용성에 의존하는 잘못된 이유 사실 매우 빠르게 더 복잡해집니다. MySQL 클러스터를 예로 들어 보겠습니다. 예, 패치를 위해 머신을 재부팅하면 고가용성으로 인해 MySQL 클러스터가 계속 실행됩니다. 하지만 패치를 위해 노드를 종료했다가 다시 시작하면 입력해야 하는 데이터의 백로그가 생성된다는 점을 명심하세요. 이 프로세스를 완료하는 데 시간이 오래 걸릴 수 있습니다. 말할 필요도 없이 모든 데이터베이스 호스트는 동일한 데이터를 확인해야 합니다. 위험은 재동기화 프로세스에서 발생합니다. 이미 종료하고 패치를 적용한 동안 다른 노드가 다운되면 최종 유효한 쿼럼이 손실될 수 있습니다. 즉, 데이터에 대한 '진실'을 담고 있는 서버의 수가 허용 가능한 수준보다 낮을 수 있습니다. 이 상태에서 복구하는 것은 어렵고 복잡할 수 있으며 데이터가 손실될 수도 있습니다. 7. 유지 관리를 위해 고가용성에 의존하지 마세요 대신 기술 팀은 단순히 고가용성 인프라가 스트레스를 견딜 수 있기를 바라기보다는 패치되는 시스템에 대한 전체 중복성을 설정하는 등 다른 솔루션에 의존해야 합니다. 또는 가능하다면 하여 패치를 설치하기 위해 서비스를 다시 시작할 필요가 없습니다. 그럼에도 불구하고 유지 관리 작업을 위해 고가용성에 의존하는 것은 우려스러운 조짐을 보이고 있습니다. 자세히 살펴보면 패치 작업을 수행하기 위해 고가용성에 의존하도록 사용자에게 지시하는 공급업체의 공식 지침을 찾을 수도 있습니다. 사용자는 한 노드가 패치 작업을 위해 오프라인 상태일 때 다른 노드에 문제가 없기를 바랄 뿐입니다. 고가용성은 많은 애플리케이션에 중요하며 다른 많은 애플리케이션에도 유익합니다. 적절하게 구성된 MySQL 데이터베이스는 거의 완벽한 가용성을 제공할 수 있지만 이것이 기술 팀이 가용성을 당연시할 수 있다는 의미는 아닙니다. 유지 관리 지름길을 유지하기 위해 고가용성 아키텍처를 남용하는 것은 바람직하지 않습니다. 위험은 언뜻 보이는 것보다 더 큽니다. 대신 시스템 관리자는 고가용성 솔루션의 기능을 저하시키지 않고 유지 관리 작업을 수행하기 위해 중복성 및 라이브 패치를 포함한 입증된 대안을 찾아야 합니다. 원본 주소: https://tuxcare.com/understanding-mysql-high-availability-good-and-bad-reasons-to-use-it/ 번역 주소: https://learnku.com/mysql /t/71681 [관련 권장 사항: mysql 비디오 튜토리얼]
제품을 살펴볼 수도 있습니다. 5. 고가용성에 의존해야 하는 좋은 이유…
매우 중요한 애플리케이션
고가용성은 장애 발생 시 시스템의 정상적인 작동을 보장하는 것입니다. 장애에 대한 이러한 본질적인 보호는 고가용성을 위해 강력하고 무책임한 시스템 유지 관리에 의존하고 아무도 이를 눈치채지 못하게 하는 무임승차가 아닙니다.
8. 끝
위 내용은 유지 관리를 위해 MySQL 고가용성에 의존해서는 안 되는 이유에 대해 이야기해 보겠습니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!