Разделение журналов репликации MySQL
У нас есть настройка репликации MySQL с сайта на сайт. Раб - это просто резервная копия, используемая для отчетов и т. Д. (Без записи) Насколько я могу судить, все идет хорошо.
Однако серверу быстро не хватает места в журналах репликации раздела mys ql.
*************************** 1. row ***************************
Slave_IO_State: Waiting for master to send event
Master_Host:
Master_User:
Master_Port:
Connect_Retry: 60
Master_Log_File: mysql-bin.000006
Read_Master_Log_Pos: 43158527
Relay_Log_File: mysql-relay-bin.000015
Relay_Log_Pos: 43158672
Relay_Master_Log_File: mysql-bin.000006
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB: mysql
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: 43158527
Relay_Log_Space: 43158870
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: 0
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 0
Last_IO_Error:
Last_SQL_Errno: 0
Last_SQL_Error:
Вот где возникает путаница. Я хочу реализовать expire_logs_days до 3 дней или около того...
Однако я боюсь нарушить репликацию, потому что;
Master_log_file = 006 и его дата 18 ноября.
-rw-rw----. 1 mysql mysql 20K Nov 3 15:36 mysql-bin.000001
-rw-rw----. 1 mysql mysql 748K Nov 3 15:36 mysql-bin.000002
-rw-rw----. 1 mysql mysql 1.1G Nov 18 09:06 mysql-bin.000003
-rw-rw----. 1 mysql mysql 216M Nov 18 09:22 mysql-bin.000004
-rw-rw----. 1 mysql mysql 125 Nov 18 09:39 mysql-bin.000005
-rw-rw----. 1 mysql mysql 1.1G Nov 18 11:34 mysql-bin.000006
-rw-rw----. 1 mysql mysql 1.1G Nov 18 11:41 mysql-bin.000007
-rw-rw----. 1 mysql mysql 1.1G Nov 18 14:23 mysql-bin.000008
-rw-rw----. 1 mysql mysql 1.1G Nov 18 14:29 mysql-bin.000009
-rw-rw----. 1 mysql mysql 1.1G Nov 19 08:57 mysql-bin.000010
-rw-rw----. 1 mysql mysql 366M Nov 20 09:37 mysql-bin.000011
-rw-rw----. 1 mysql mysql 60M Nov 20 12:09 mysql-bin.000012
-rw-rw----. 1 mysql mysql 23K Nov 20 12:10 mysql-bin.000013
-rw-rw----. 1 mysql mysql 1.1G Nov 23 00:43 mysql-bin.000014
-rw-rw----. 1 mysql mysql 1.1G Nov 26 12:03 mysql-bin.000015
-rw-rw----. 1 mysql mysql 251M Nov 27 11:33 mysql-bin.000016
-rw-rw----. 1 mysql mysql 304 Nov 26 12:03 mysql-bin.index
Вопросы
Нужно ли устанавливать более высокий порог дней для истечения срока действия файла журнала?
IE; "SET GLOBAL expire_logs_days = 3;" сломать мою репликацию, потому что mysql-bin.000006 является текущим master_log_file?
Возможно, ограничение предельного размера файла журнала в дополнение к истечению срока годности является решением?
Я искал их для оригинальной идеи, но я хочу быть уверен на 100%: https://dba.stackexchange.com/questions/41050/is-it-safe-to-delete-mys ql-bin-files http://dev.mys ql.com/doc/refman/5.1/en/replication-administration-status.html
заранее спасибо
1 ответ
Вы смотрите на двоичные журналы вашего ведомого. Ваш раб имеет явно log_bin
набор переменных, и он заполняет свои диски своими собственными двоичными журналами (не журналами мастера, их имена, вероятно, содержат relay
word, так как вы используете значения по умолчанию в двоичном и релейном именах журналов). Вы можете просмотреть их с show master status
, Чтобы решить эту проблему (если к этому ведомому устройству не подключены подчиненные), вы можете установить log_bin
переменная в OFF. Да, вы также можете установить expire_logs_days
переменная на ведомом устройстве, и она ничего не сломает (потому что она контролирует дату окончания двоичных журналов на сервере, на котором она настроена), но если они вам вообще не нужны - зачем их хранить?