Tôi có một bậc thầy có 298 tệp bin chuyển tiếp gần đây như ngày hôm nay, sẽ hoạt động tốt trở lại sau 298 ngày.

Không có định nghĩa nhật ký chuyển tiếp trong .cnf

và

mysql> show variables like '%relay%';
+---------------------------------+----------------+
| Variable_name                   | Value          |
+---------------------------------+----------------+
| innodb_overwrite_relay_log_info | OFF            |
| max_relay_log_size              | 0              |
| relay_log                       |                |
| relay_log_index                 |                |
| relay_log_info_file             | relay-log.info |
| relay_log_purge                 | ON             |
| relay_log_space_limit           | 0              |
+---------------------------------+----------------+

Đặt lại nô lệ xóa chúng, nhưng sau đó chúng mới bắt đầu được tái sinh.

Bất cứ ý tưởng những gì gây ra điều này? Làm thế nào để ngăn chặn nó?

EDITS ĐỂ YÊU CẦU

Các phê bình chung của cnf đều được hoan nghênh nhưng chúng ta hãy ghi nhớ chủ đề OP.

---- cnf request

[mysqld]
character_set_server = utf8

max_connections=200
max_user_connections=160
max_connect_errors=10000

userstat_running = 1

log_warnings
slow_query_log=1
slow_query_log_file=/var/log/mysql/mysql-slow.log
long_query_time=2


innodb_file_per_table

innodb_open_files=2048

innodb_additional_mem_pool_size=1M

innodb_buffer_pool_size=512M

innodb_log_buffer_size=1M

innodb_log_file_size=128M

innodb_autoextend_increment=16


innodb_flush_method=O_DIRECT


datadir=/var/lib/mysql/


tmpdir=/var/lib/mysql_ramdisk


server-id=2

log-bin = /var/log/mysql/mysql-bin
log-bin-index = /var/log/mysql/mysql.index

key_buffer_size = 800M

preload_buffer_size = 256K

max_allowed_packet = 8M
table_cache = 512
sort_buffer_size = 8M
join_buffer_size = 8M

read_buffer_size = 2M
read_rnd_buffer_size = 2M
thread_cache_size = 32
query_cache_size = 32M
query_cache_limit = 16M


myisam_sort_buffer_size = 2000M


tmp_table_size = 64M
max_heap_table_size = 64M

---- now for the cli requests

mysql> show slave status\G
Empty set (0.00 sec)

mysql> show master status;
+---------------------+----------+--------------+------------------+
| File                | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+---------------------+----------+--------------+------------------+
| awesome-bin.xxxxxxx | yyyyyyyy |              |                  |
+---------------------+----------+--------------+------------------+
1 row in set (0.00 sec)



---- version


mysql> select version();
+--------------------+
| version()          |
+--------------------+
| 5.1.47-rel11.1-log |
+--------------------+
1 row in set (0.00 sec)

Nếu một Master có các bản ghi chuyển tiếp, thì Master cũng phải là một Slave ở giữa một số cấu trúc liên kết sao chép (ví dụ: Master / Master, Daisy-Chained Replication)

Điều gì có thể gây ra các bản ghi chuyển tiếp phát triển như thế này?

ĐẠI DIỆN

Bản sao MySQL bị hỏng khi luồng IO hoặc luồng SQL chết dưới các SCENARIOS này:

• SCENARIO # 1 : Khi luồng IO và luồng SQL bị tắt, một trong hai điều xảy ra
  • MySQL đã được bắt đầu với skip-slave-startkích hoạt
  • Ai đó / cái gì đó chạy STOP SLAVE;
• SCENARIO # 2 : Khi luồng IO chết
  • không có gì có thể chồng lên các bản ghi chuyển tiếp
  • Chuỗi SQL xử lý tất cả các lệnh SQL trong nhật ký chuyển tiếp hoặc cho đến khi xảy ra lỗi SQL
• SCENARIO # 3 : Khi luồng SQL chết
  • Xảy ra lỗi SQL khi xử lý lệnh SQL
  • Chạy SHOW SLAVE STATUS\Gcho bạn thấy Last_ErrnovàLast Error
  • IO Thread tiếp tục thu thập các lệnh SQL từ Master, làm cho các bản ghi chuyển tiếp phát triển

Đó là vấn đề # 3 đó là vấn đề. Khi luồng SQL chết do lỗi SQL, không có cơ chế tích hợp nào trong Bản sao MySQL kích hoạt luồng IO để ngắt kết nối .

SỰ GIỚI THIỆU

Cách duy nhất để kiểm soát sự tăng trưởng của nhật ký chuyển tiếp là đặt giới hạn cho nó

[mysqld]
relay_log_space_limit=4G

Đặt rơle_log_space_limit đặt giới hạn 4G.

Khi một bản ghi chuyển tiếp được xử lý hoàn toàn

• nó được xoay ra
• luồng SQL bắt đầu làm việc trên nhật ký chuyển tiếp tiếp theo
• luồng I / O bắt đầu tải SQL từ Master từ vị trí cuối cùng mà nó rời khỏi, miễn là có đủ tự do trên đĩa

TIẾNG VIỆT

Nếu Master đã từng là Slave và không cần thiết nữa, hãy tắt nó đi.

mysql -e"STOP SLAVE; CHANGE MASTER TO MASTER_HOST='';"
rm -f /var/lib/mysql/master.info

Nếu Master là Slave, hãy sửa lỗi SQL.

Tôi sẽ đề nghị điều này nếu lỗi SQL xảy ra:

STOP SLAVE;
SET GLOBAL sql_slave_skip_counter = 1;
START SLAVE SQL_THREAD;

sau đó chạy SHOW SLAVE STATUS\Gmỗi phút để xem các bản ghi chuyển tiếp có được xử lý và xoay không.

Không nhìn thấy my.cnf của bạn, bạn không thể trả lời câu hỏi này, nhưng tôi cũng khuyên bạn nên đăng đầu ra SHOW SLAVE STATUS \ G - có thể là nô lệ của bạn thực sự bị bỏ xa? Điều đó sẽ giữ các bản ghi chuyển tiếp xung quanh. Là luồng SQL Slave đang chạy?

Có thể là tập tin my.cnf được cấu hình sai và nhật ký nhị phân chính được đặt tên là nhật ký chuyển tiếp?

Hoặc có thể chủ của bạn có các cài đặt sao chép được mã hóa cứng trong tệp my.cnf, được chọn khi khởi động lại phiên bản MySQL.

EDIT: Bạn đã che dấu tên tệp binlog thực tế trong show master statusđầu ra? Tôi đang hỏi vì cài đặt trong my.cnf không khớp với tên binlog. Nếu vậy, bạn có thể cung cấp tên tệp thực tế và đầu ra show slave statusnhư Aaron đã đề cập không? Cho đến nay, ngoài tên không khớp cho bin-log, không có gì nổi bật trong tệp my.cnf của bạn.

Thực hiện lệnh RESET SLAVE. Nó sẽ làm sạch các bản ghi rơle và tái tạo một bản ghi mới. Nhưng, nó sẽ không sử dụng cái mới. Bạn có thể kiểm tra bằng cách chạy sau lệnh FLUSH LOGS, máy chủ sẽ không tạo nhật ký chuyển tiếp thứ hai.