|
|
| Comment : 1 |
| |
| From. ( ) Date : 2021-03-13 Time : 09:08:28 |
| Comment : 2 |
| Please do not just delete them in the OS. You need to let mysqld do that for you. Here is how mysqld manages it: The file mysql-bin.index keeps a list of all binary logs mysqld has generated and auto-rotated. The mechanisms for cleaning out the binlogs in conjunction with mysql-bin.index are: PURGE BINARY LOGS TO 'binlogname'; PURGE BINARY LOGS BEFORE 'datetimestamp'; These will clear all binary logs before the binlog or timestamp you just specified. For example, if you run PURGE BINARY LOGS TO 'mysql-bin.000223'; this will erase all binary logs before 'mysql-bin.000223'. If you run PURGE BINARY LOGS BEFORE DATE(NOW() - INTERVAL 3 DAY) + INTERVAL 0 SECOND; this will erase all binary logs before midnight 3 days ago. If you want to have binlog rotated away automatically and keep 3 days woth, simply set this: mysql> SET GLOBAL expire_logs_days = 3; then add this to /etc/my.cnf [mysqld] expire-logs-days=3 and mysqld will delete them logs for you SHOW SLAVE STATUS\G This is critical. When you run SHOW SLAVE STATUS\G, you will see two binary logs from the Master: Master_Log_File Relay_Master_Log_File When replication has little or no lag these are usually the same value. When there is a lot of replication lag, these values are different. Just to make it simple, choose whatever Relay_Master_Log_File is, and go back to the Master and run PURGE BINARY LOGS TO 'Whatever Relay_Master_Log_File Is'; That way, replication is not interrupted. Give it a Try !!! |
| From. ฟ ( ฟ ) Date : 2015-11-03 Time : 10:58:38 |
| Comment : 3 |
| [root@ns165 ~]# cat /usr/local/directadmin/conf/mysql.conf user=da_admin passwd=xxxxxxxxxxx |
| From. a ( a ) Date : 2015-11-03 Time : 10:50:17 |
| Back To Comment |
|
|