안녕하세요.

크롬은 2020-01월부터 파폭이나 익스등은 2020-03월부터 tls 1.1 지원 중단
어차피 apache의 경우 거의 대부분 디폴트 설정이 tls 1.1 과 tls 1.2가 같이 포함돼있기 때문에 브라우저에서 지원 종료해도 실제 서비스에는 문제가 없을것이다.(SSLProtocol all -SSLv2 -SSLv3 이렇게 설정 돼 있음)

PS.
tls 1.3 지원 : openssl 1.1.1 이상 / nginx 1.13.0 이상 / apache 2.4.37 이상
ㄴ따라서 아직 tls 1.3 안되는서버도 적잖이 있다.

하지만 오래된 서버의 경우 openssl 버전이 낮아서 tls 1.2가 지원하지 않을 수 있다.

현재 도메인의 TLS 지원 여부 확인 사이트에서 확인 가능
https://www.ssllabs.com/ssltest/

좀 더 도메인 자체의 보안등급을 올리고자 한다면 아래와 같이 설정하여 tls 1.1을 제외해주면 됩니다.
(tls 1.1 제외되는 이유는 poodle 이라는 공격기법 때문이라한다. tls 1.1 tls 1.2 가 아파치에 동시 적용 돼 있으면 브라우저에서 tls 1.1을 지원 중단하여도 무슨 다운그레이드 협약? 뭐 그런거 때문에 tls 1.1로 사용 할 수 있다고 한다. 즉 보안에 취약)

아파치 서버의 경우 위와 같이 설정법을 통해 TLS 1.2(아파치 2.4.37 이상이면 tls 1.3까지)만 적용되도록 하면 될 듯

아파치 2.2 면 SSLProtocol -all +TLSv1.2  이런식으로 전부 빼버리고 TLS v1.2만 추가해주고

아파치 2.4.37 이상이면 SSLProtocol -all +TLSv1.2 +TLSv1.3 이런식으로 전부 빼버리고 +TLSv1.2 +TLSv1.3 만 추가
(엔진엑스나 java등은 그에 맞게 구글링하면 될듯합니다.)

만약 openssl 버전이 낮아서 tls 1.2 지원이 안되면

1.취약점 해결된 openssl 버전 새롭게 설치(기존 openssl 건들면 안되고 추가로 설치 해줘야 함)
2.새로 설치한 openssl을 참조하는 apache를 새로 설치
3.새로 설치된 mod_ssl.so 를 기존에 사용하던 mod_ssl.so 에 복사하던가 & 아니면 기존에 사용하던 apache 설정파일을 새로 설치한 apache에 넣어주던가 하면 됩니다.
(기왕이면 apache 버전도 같이 올려주는게 좋긴 할 듯)

요약하자면
1.2020년부터 tls 1.1 지원 중단(tls 1.1로만 사용되던 구버전의 apache등은 사이트 안나올 가능성 있음)
ㄴtls 1.2 지원 여부 확인 사이트 https://www.ssllabs.com/ssltest/

2.적잖이 옛날버전의 아파치도 tls 1.2 는 지원함(따라서 왠만하면 사이트 장애는 안날듯)
ㄴ하지만 보안에 취약(poodle)

3.따라서 관리 서버면 tls 1.1을 빼주는게 좋다.
ㄴtls 1.1까지만 지원되는 환경이라면 업그레이드 필요

마스터1대, 슬레이브 3대로 구성된 디비 서버들인데     

          Slave_IO_State: Waiting for master to send event
                   Master_Host: 192.168.0.212
                   Master_User: slave1
                   Master_Port: 3813
                 Connect_Retry: 60
               Master_Log_File: mariadb-bin.602137
           Read_Master_Log_Pos: 163251227
                Relay_Log_File: localhost-relay-bin.013096
                 Relay_Log_Pos: 100492948
         Relay_Master_Log_File: mariadb-bin.602137
              Slave_IO_Running: Yes
             Slave_SQL_Running: No
               Replicate_Do_DB: 
           Replicate_Ignore_DB: 
            Replicate_Do_Table: 
        Replicate_Ignore_Table: 
       Replicate_Wild_Do_Table: 
   Replicate_Wild_Ignore_Table: 
                    Last_Errno: 1032
                    Last_Error: Could not execute Delete_rows_v1 event on table gameworkr.offer_account; Can't find record in 'offer_account', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mariadb-bin.602137, end_log_pos 101337573
                  Skip_Counter: 0
           Exec_Master_Log_Pos: 100492647
               Relay_Log_Space: 700123700
               Until_Condition: None
                Until_Log_File: 
                 Until_Log_Pos: 0
            Master_SSL_Allowed: No
            Master_SSL_CA_File: 
            Master_SSL_CA_Path: 
               Master_SSL_Cert: 
             Master_SSL_Cipher: 
                Master_SSL_Key: 
         Seconds_Behind_Master: NULL
 Master_SSL_Verify_Server_Cert: No
                 Last_IO_Errno: 0
                 Last_IO_Error: 
                Last_SQL_Errno: 1032
                Last_SQL_Error: Could not execute Delete_rows_v1 event on table gameworkr.offer_account; Can't find record in 'offer_account', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log mariadb-bin.602137, end_log_pos 101337573
   Replicate_Ignore_Server_Ids: 
              Master_Server_Id: 1
                Master_SSL_Crl: 
            Master_SSL_Crlpath: 
                    Using_Gtid: No
                   Gtid_IO_Pos: 
       Replicate_Do_Domain_Ids: 
   Replicate_Ignore_Domain_Ids: 
                 Parallel_Mode: conservative
                     SQL_Delay: 0
           SQL_Remaining_Delay: NULL
       Slave_SQL_Running_State: 
              Slave_DDL_Groups: 552
Slave_Non_Transactional_Groups: 0
    Slave_Transactional_Groups: 2545153712

위와같이 1032 에러 발생, 리플리케이션 장애발생

먼저
STOP SLAVE; SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;START SLAVE;
슬레이브 1번서버 에러 스킵후 데이터를 확인해보니 에러 난 슬레이브1번 서버의 데이터가 정상이고 나머지가 비정상임을 확인

즉
마스터, 슬레이브2,3 의 데이터는 비정상이고 슬레이브1의 데이터가 정상이기에 슬레이브 1의 데이터를 마스터, 슬레이브2,3에 옮겨야 한다.

아래와 같이 작업 진행

1.모든 디비서버들 외부에서의 접속 차단(iptables로 디비 서버끼리는 통신되도록 하고 나머지 외부에서 들어오는건 차단) 그리고 한 1~2분정도 기다려서 리플리케이션 확인

2.슬레이브1 서버에서 정상 테이블 덤프 - drop table이나 no create 옵션 사용하여 insert 구문만 들어가도록 덤프

3.마스터 서버에서 문제있는 테이블 트렁케이트 후 기달려서 동기화 까지 확인
4.마스터 서버에 덤프받은 디비 복원 후 동기화 확인

ps.

디비 차단 안한상태에서, 즉 서비스에 최대한 문제 없이 진행하고자 한다면 아래와 같이 했으면 됐을듯싶다.

1.문제있는 테이블 수정권한이 있는 계정의 수정권한을 빼서 해당 테이블 변경되지 않도록 설정
2.나머지는 기존처럼 정상 테이블 백업 후 마스터에서 truncate 한 뒤 복원하기