Mam pytanie dotyczące usuwania dzienników binarnych w środowisku replikacji:

Mamy środowisko z 1 masterem i 2 slaveami (działającymi w mysql 5.5). Czasami napotykamy problemy z przestrzenią podczas ciężkich czasów przetwarzania, w wyniku których katalog dziennika bin zapełnia się. Dzienniki wygasają co 3 dni. Zastanawiałem się, czy istnieje powód, dla którego logi powinny być przechowywane przez 3 dni na wszystkich skrzyniach - master i obaj slave? Czy miałoby sens, na przykład, przechowywanie dzienników przez 3 dni u mistrza, a przez 1 dzień w niewolnikach? Jak najlepiej to zrobić?

Dziękuję Ci!

NIEWOLNIK

Jeśli Twoi Niewolnicy nie są Mistrzami, wtedy Niewolnicy w ogóle nie potrzebują rejestrowania binarnego. Możesz nałożyć limit na ilość miejsca w dzienniku przekaźników zgromadzonym przez Slave. Aby dławić dzienniki przekaźnika przy 4G, dodaj relay_log_space_limitdo /etc/my/.cnf na każdym Slave

[mysqld]
relay_log_space_limit=4G

i zrestartuj mysql

Jeśli nie możesz tego ustawić, przynajmniej powinieneś mieć jakieś ostrzeżenie, które to robi SHOW SLAVE STATUS\Gi sprawdzić wartość Relay_Log_Space(całkowita liczba bajtów zużyta przez dzienniki przekazywania).

MISTRZ

Jeśli chodzi o Mistrza, możesz ustawić expire_logs_daysna 1, ale mam dla ciebie surowe ostrzeżenie ...

Jeśli replikacja się zepsuje, masz 1 dzień na jej naprawienie. W przeciwnym razie dziennik binarny na serwerze głównym może się obracać i nie można uruchomić żadnego polecenia CHANGE MASTER TO, aby wyrównać replikację. Wyszedłbym expire_logs_dayso 3 na Mistrza.

SUGESTIA # 1

Jeśli masz do czynienia z przetwarzaniem zbiorczym w ciągu nocy, być może powinieneś uruchomić procesy zbiorcze w Master SET SQL_LOG_BIN=0;na początku sesji. To oczywiście nie powiela się w Slave. Możesz wykonać to samo obciążenie masowe równolegle do obu urządzeń podrzędnych.

SUGESTIA # 2

Inną rzeczą, którą możesz zrobić, aby zarządzać akumulacją dzienników binarnych Master, jest to.

Uruchom SHOW SLAVE STATUS\Gna obu niewolnikach. Patrzeć Relay_Master_Log_File. Reprezentuje dziennik binarny na Master, którego ostatnie polecenie zostało wykonane na Slave.

*************************** 1. row ***************************
             Slave_IO_State: Waiting for master to send event
                Master_Host: 10.4.92.250
                Master_User: replicant
                Master_Port: 3306
              Connect_Retry: 60
            Master_Log_File: mysql-bin.009677
        Read_Master_Log_Pos: 855227755
             Relay_Log_File: relay-bin.000674
              Relay_Log_Pos: 757296783
      Relay_Master_Log_File: mysql-bin.009590
           Slave_IO_Running: Yes
          Slave_SQL_Running: Yes
            Replicate_Do_DB:
        Replicate_Ignore_DB:
         Replicate_Do_Table:
     Replicate_Ignore_Table:
    Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
                 Last_Errno: 0
                 Last_Error:
               Skip_Counter: 0
        Exec_Master_Log_Pos: 757296646
            Relay_Log_Space: 94274010765
            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: 80561
1 row in set (0.00 sec)

W tym przykładzie Relay_Master_Log_File to mysql-bin.009590. Wszystkie dzienniki binarne przed tym można usunąć z Master. Możesz uruchomić to na Master:

PURGE BINARY LOGS TO 'mysql-bin.009590';

Spowoduje to usunięcie starszych dzienników i pozostawi replikację w takcie.

CAVEAT

Dzienniki binarne to pliki, które szeregowo kompilują (podobnie jak kolejka FIFO) wszystkie zakończone transakcje SQL jako instrukcję SQL lub zmianę wiersza. Dziennik przekazywania jest plikiem, który zbiera wpisy dziennika binarnego ze zdalnego serwera (zwanego także Master).

W replikacji MySQL

1. Master musi mieć włączone dzienniki binarne
2. Slave kompiluje logi przekaźnikowe
3. Po przetworzeniu całego kodu SQL w dzienniku przekazywania jest on usuwany
4. W Slave, gdy na serwerze DB jest więcej niż jeden dziennik przekazywania, może to oznaczać, że replikacja pozostaje w tyle, ponieważ wątek IO zbiera SQL od Master szybciej, niż wątek SQL może przetwarzać dzienniki przekazywania.
5. Użycie relay_log_space_limit zapobiega gromadzeniu się replikacji i potencjalnemu zapełnianiu dysku. Dzienniki przekaźników obracają się zgodnie z zasadą nr 3
6. Serwer DB może być jednocześnie Master i Slave. To jedyna okoliczność, w której Slave musi mieć włączone dzienniki binarne. W tym scenariuszu serwer DB będzie zawierał zarówno dzienniki binarne, jak i dzienniki przekazywania.

Jeśli przejdziesz w tryb failover do Slave i chcesz uczynić go mistrzem

• usługa mysql stop
• Dodaj log-bin=mysql-bindo /etc/my.cnf w Slave
• usługa mysql start

Będziesz musiał skonfigurować replikację innych Slaveów na nowo promowanym Master i upewnić się, że dane w Slave są zgodne z nowo promowanym Master

AKTUALIZACJA 2012-08-13 17:47 EDT

Zgodnie z dokumentacją MySQL dotyczącą relay-logopcji należy ją zdefiniować. Oto dlaczego:

Ze względu na sposób, w jaki MySQL analizuje opcje serwera, jeśli podasz tę opcję, musisz podać wartość; domyślna nazwa basenowa jest używana tylko wtedy, gdy opcja nie jest faktycznie określona Jeśli użyjesz opcji --relay-log bez określania wartości, może to spowodować nieoczekiwane zachowanie; zachowanie to zależy od innych użytych opcji, kolejności, w jakiej zostały określone, oraz od tego, czy są one określone w wierszu poleceń, czy w pliku opcji. Aby uzyskać więcej informacji o tym, jak MySQL obsługuje opcje serwera, zobacz Sekcja 4.2.3, „Określanie opcji programu”.