CentOS 7을 사용한 이후로 일반 하트비트 설정에서 Pacemker로 전환했습니다.
주로 한 노드에서 활성화되고 장애 조치가 발생하면 두 번째 노드로 전환하는 IP 리소스가 있습니다. 또한 장애 조치가 발생할 경우 일부 스크립트를 실행합니다. 특별한 것은 없습니다.
리소스가 항상 기본 노드에서 시작되도록 하려면 다음을 사용합니다.
pcs constraint location Cluster_IP prefers server1=master-server
나도 사용
pcs resource defaults resource-stickiness=INFINITY
장애 조치 후 리소스가 다시 이동하는 것을 방지합니다.
마스터가 실패하는 경우(예: 하드웨어 오류) 이것은 나에게 잘 작동합니다.
장애 조치에 시간이 좀 걸리더라도 문제가 되지 않으므로 짧은 분할 브레인의 경우 일종의 지연을 구현하고 싶습니다.
어떤 작업을 수행하기 전에 슬레이브는 이 ~2분 안에 마스터에 다시 연결할 수 있는 경우를 대비하여 인계받기 전에 ~2분을 기다려야 합니다.
가장 좋은 방법은 무엇인지 궁금합니다.
답변1
저는 Corosync에서 토큰 시간 제한을 10초 이상으로 설정한 적이 없지만 값을 token밀리초 단위로 corosync.conf120 120000초로 늘리거나 설정할 수 있습니다. 의 섹션 token에 정의되어야 합니다 . 자세한 내용은.totem{}corosync.confman corosync.conf
이는 네트워크가 파손될 때 Corosync가 120초 동안 노드가 작동하지 않는다고 선언하는 것을 방지해야 합니다.
답변2
초 수를 사용하여 리소스의 모니터링 간격을 변경한 다음 op monitor interval=Ns리소스 의 를 로 설정할 수 있습니다 . 모니터링 간격에서 초기 오류가 발생하는 시점에 따라 총 120~240초의 지연이 나타날 수 있다는 설정을 염두에 두세요 .Nmigration-threshold2120s
migration-threshold여기에는 적용된 실패 카운터가 성공 시 재설정되지 않는다는 점에서 다른 주의 사항이 있습니다 . 그렇게 하려면 설정하거나 수동으로 개입해야 합니다 failure-timeout.
op monitor interval=120s, migration-threshold=2및 failure-timeout=121s설정 을 사용하여 resource-stickiness예상한 기능을 제공하는지, 그리고 원래 마스터가 복구될 때 실패 카운터가 어떻게 작동하는지 테스트해야 합니다. 수동 개입이 필요할 수도 있지만 이에 대해 100% 확신할 수는 없습니다.