Lỗi 1236 - Triệu không thể tìm thấy tên tệp nhật ký đầu tiên trong tệp chỉ mục nhật ký nhị phân


10

Thiết lập của chúng tôi:

  • Thạc sĩ: MariaDB 10.0,21
  • Nô lệ: MariaDB 10.0.17

Bản sao đã hoạt động tốt cho đến gần đây tại thời điểm DB của nô lệ phải được khôi phục từ bãi chứa. Tôi đã thực hiện tất cả các bước cần thiết: Kết xuất DB của chủ, chuyển kết xuất sang nô lệ, thả DB cũ, thực hiện kết xuất để khôi phục DB, thực hiện CHANGE MASTERlệnh thích hợp và cuối cùng START SLAVE.

Tôi đang nhận được lỗi: Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'

Tệp nhật ký đầu tiên mà nô lệ cần từ chủ là mysql-bin.000289. Tôi có thể thấy rằng điều này hiện diện trên chủ: nhập mô tả hình ảnh ở đây

Tôi cũng có thể thấy rằng chỉ mục nhật ký nhị phân trên bản gốc dường như có một mục nhập cho tệp nhật ký này: nhập mô tả hình ảnh ở đây

Bản sao vẫn không hoạt động - Tôi tiếp tục nhận được cùng một lỗi. Tôi không có ý tưởng - tôi nên kiểm tra cái gì tiếp theo?


Cập nhật: Đầu ra SHOW SLAVE STATUS\Gtheo yêu cầu:

MariaDB [(none)]> SHOW SLAVE STATUS\G
--------------
SHOW SLAVE STATUS
--------------

*************************** 1. row ***************************
               Slave_IO_State: 
                  Master_Host: 127.0.0.1
                  Master_User: replication
                  Master_Port: 1234
                Connect_Retry: 60
              Master_Log_File: mysql-bin.000289
          Read_Master_Log_Pos: 342
               Relay_Log_File: mysqld-relay-bin.000002
                Relay_Log_Pos: 4
        Relay_Master_Log_File: mysql-bin.000289
             Slave_IO_Running: No
            Slave_SQL_Running: Yes
              Replicate_Do_DB: xxx_yyy,xxx_zzz
          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: 342
              Relay_Log_Space: 248
              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: 1236
                Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'
               Last_SQL_Errno: 0
               Last_SQL_Error: 
  Replicate_Ignore_Server_Ids: 
             Master_Server_Id: 3
               Master_SSL_Crl: 
           Master_SSL_Crlpath: 
                   Using_Gtid: No
                  Gtid_IO_Pos: 
1 row in set (0.00 sec)

Thông tin yêu cầu bổ sung:

root@master [818 18:54:22 /var/lib/mysql]# ls -l /var/lib/mysql/mysql-bin.000289
-rw-rw---- 1 mysql mysql 1074010194 May 19 03:28 /var/lib/mysql/mysql-bin.000289
root@master [819 18:54:29 /var/lib/mysql]# ls mysql-bin.00029*
mysql-bin.000290  mysql-bin.000291  mysql-bin.000292 #(Yes, it was created)
root@master [821 18:56:52 /var/lib/mysql]# mysql -uroot -p
Enter password: 
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 6345382
Server version: 10.0.21-MariaDB-log MariaDB Server

Copyright (c) 2000, 2015, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> SHOW BINARY LOGS;
+------------------+------------+
| Log_name         | File_size  |
+------------------+------------+
| mysql-bin.000279 | 1074114047 |
| mysql-bin.000280 | 1074004090 |
| mysql-bin.000281 | 1074035416 |
| mysql-bin.000282 | 1073895128 |
| mysql-bin.000283 | 1073742000 |
| mysql-bin.000284 | 1074219591 |
| mysql-bin.000285 | 1074184547 |
| mysql-bin.000286 | 1074217812 |
| mysql-bin.000287 | 1022733058 |
| mysql-bin.000288 |     265069 |
| mysql-bin.000289 | 1074010194 |
| mysql-bin.000290 | 1074200346 |
| mysql-bin.000291 |  617421886 |
| mysql-bin.000292 |     265028 |
+------------------+------------+
14 rows in set (0.00 sec)

MariaDB [(none)]> exit
Bye
root@master [821 18:57:24 /var/lib/mysql]# mysqlbinlog mysql-bin.000289 > /tmp/somefile.txt
root@master [822 18:58:13 /var/lib/mysql]# tail /tmp/somefile.txt 
# at 1074010124
#160519  3:28:59 server id 5  end_log_pos 1074010151    Xid = 417608063
COMMIT/*!*/;
# at 1074010151
#160519  3:28:59 server id 5  end_log_pos 1074010194    Rotate to mysql-bin.000290  pos: 4
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
root@master [823 18:58:31 /var/lib/mysql]# 

/etc/my.cnf.d/server.cnf (trích):

# BINARY LOGGING #
log-bin                        = /var/lib/mysql/mysql-bin
expire-logs-days               = 14
sync-binlog                    = 1

Chỉnh sửa: Postion 342 dường như tồn tại:

root@master [826 12:15:33 /var/lib/mysql]# grep "end_log_pos 342 " /tmp/somefile.txt
#160517 14:43:13 server id 5  end_log_pos 342   Binlog checkpoint mysql-bin.000288

Cũng hãy cẩn thận vì phiên bản chính của bạn gần đây hơn một chút so với phiên bản nô lệ của bạn. Mặc dù phiên bản nô lệ có thể cao hơn (vì chắc chắn sẽ hiểu tất cả các lệnh / chức năng / tính năng), nhưng nếu Master gần đây hơn, nó có thể gọi ra một thứ mà Slave chưa bao giờ nghe thấy. Tôi nghi ngờ điều đó sẽ không xảy ra trong một sự khác biệt sửa đổi nhỏ như vậy, nhưng không thể loại trừ và chắc chắn sẽ là Arcane trong cùng cực và khó tìm. Ngoài ra: dòng chính thức là chủ gần đây không được hỗ trợ.
TheSatinKnight

Câu trả lời:


6

Bạn dường như không kết nối với chủ mà bạn nghĩ rằng bạn là. Theo nhật ký nhị phân của bạn trên bản gốc mà bạn dường như có:

# 160519 3:28:59 id máy chủ 5

Nhưng theo TÌNH TRẠNG SHOW SLAVE chúng ta thấy:

         Master_Server_Id: 3

Và hơn nữa bạn dường như đang kết nối trên localhost, nhưng bạn ngụ ý chủ / nô lệ của bạn nằm trên các máy chủ khác nhau:

              Master_Host: 127.0.0.1

1
Chúng tôi đang sử dụng SSH đường hầm (với autossh ) để hiển thị bản gốc từ xa tại 127.0.0.1:3305. Tôi cũng nhận thấy Master_Server_Id, nhưng tôi đoán rằng đó chỉ là tàn dư từ lâu khi chúng tôi đang sử dụng một chủ khác. Tôi đã mong đợi giá trị SHOW SLAVE STATUSđể cập nhật một khi chúng tôi đã thiết lập lại bản sao hoàn toàn. Bất kể, đây là một đề nghị tuyệt vời; Tôi sẽ kiểm tra kỹ xem chúng ta có thực sự đang kết nối với chủ đúng không!
rinogo

1
Cảm ơn bạn rất nhiều vì đã chỉ cho tôi đi đúng hướng! Chúng tôi, thực sự, kết nối với chủ sai. Tôi đã xác nhận nó bằng cách thực hiện telnet 127.0.0.1:3305- Tôi có thể thấy rằng phiên bản MySQL được báo cáo khớp với phiên bản từ chủ . Tôi nghĩ rằng nguyên nhân của vấn đề có thể là do một số quirks DNS trên mạng của chúng tôi - có vẻ như kết nối tự động đã được thiết lập sai cho domain.com, mặc dù nó được định cấu hình để kết nối với db.domain.com. Cảm ơn rất nhiều lần nữa.
rinogo

8

Nếu vẫn thất bại, bạn có thể thấy rằng bạn cần đặt lại nô lệ và khởi động lại sao chép. Từ https://www.redips.net/mysql/replication-slave-relay-log-corrupted/ :

# First note current settings
mysql> show slave status\G
# then stop slave
mysql> stop slave;
# make slave forget its replication position in the master's binary log
mysql> reset slave;
# change slave to start reading from stopped position
mysql> change master to master_log_file='mysql-bin.XXX', master_log_pos=XXX;
# start slave
mysql> start slave;

1
OP đã nhận xét rằng một câu trả lời khác là đúng (và họ đang kết nối với trường hợp sai).
ypercubeᵀᴹ

3
@ yper-trollᵀᴹ - có, nhưng một nửa điểm của Stackexchange là dành cho việc lưu trữ các câu hỏi, chắc chắn nằm ở đầu tìm kiếm của Google cho những người khác có cùng vấn đề. Tôi đã có cùng một vấn đề chính mình và đây là giải pháp cho tôi (đặc biệt là khi tôi thực sự dành hàng giờ để cố gắng giải quyết nó, bởi vì hầu hết các trang khác chỉ hiển thị cùng một câu trả lời khác). Việc câu trả lời "sai" khác có 2 lượt bình chọn là minh chứng cho điều này.
Andy Beverley

Vâng, điểm công bằng. Miễn là điều này (gợi ý) có nghĩa là được sử dụng khi tất cả những thứ khác không thành công (và được đánh dấu rõ ràng như vậy), điều đó tốt. Đó là lý do tại sao tôi chỉ bình luận và không đánh giá thấp.
ypercubeᵀᴹ

1
Câu trả lời này có hiệu quả với tôi khi không có lời khuyên nào khác được áp dụng. (Tôi đang làm việc với một binlog hiện tại, hiện tại, đã được cấu hình chính, v.v.) Đó là một câu trả lời đúng đắn và thẳng thắn là RESET SLAVE; tùy chọn nên được đề cập nổi bật hơn ở trên.
JD Baldwin

3

Thông báo lỗi là câu trả lời.

Nhìn vào đầu ra của SHOW BINARY LOGStruy vấn:

+------------------+------------+
| Log_name         | File_size  |
+------------------+------------+
| mysql-bin.000279 | 1074114047 |
| mysql-bin.000280 | 1074004090 |
| mysql-bin.000281 | 1074035416 |
| mysql-bin.000282 | 1073895128 |

Không có mysql-bin.000278 trong màn hình.

Trừ khi các bản ghi nhị phân được xoay, nội dung của mysql-bin.index là sai.

Vui lòng so sánh nội dung mysql-bin.indexvới các tệp binlog hiện có và đảm bảo chúng khớp. Bạn có thể sửa lỗi này trên Master với

mysql> PURGE BINARY LOGS TO 'mysql-bin.000279';

sau đó đi đến Slave và chạy

mysql> STOP SLAVE; START SLAVE;

Hãy thử một lần !!!


Xin chào, Rolando! Cám ơn rất nhiều về sự giúp đỡ của bạn! Thật không may, tôi vẫn còn bối rối. Ý bạn là mysql-bin.000288thay vì mysql-bin.000278? Nếu vậy, mysql-bin.000288dường như tồn tại. Điều này vẫn sẽ khắc phục vấn đề?
rinogo

PURGE BINARY LOGS TO 'mysql-bin.000279';đã cho tôi một lỗi (như dự kiến), vì nhật ký "279" không còn tồn tại (đã bị loại bỏ). PURGE BINARY LOGS TO 'mysql-bin.000288';thực hiện thành công và xóa tất cả các bản ghi nhị phân lên đến "288". Thật không may, tôi vẫn nhận được lỗi.
rinogo

Cảm ơn rất nhiều vì những gợi ý chi tiết của bạn, Rolando! Vấn đề cuối cùng là chúng tôi đã kết nối với chủ sai ( dba.stackexchange.com/a/140259/55530 ).
rinogo

2

Cập nhật: Câu trả lời này bao gồm phân loại lỗi chung. Để có câu trả lời cụ thể hơn về cách xử lý tốt nhất truy vấn chính xác của OP, vui lòng xem các câu trả lời khác cho câu hỏi này

Một trong những lỗi sao chép quan trọng nhất Có nghiêm trọng 1236 Nó có thể được kích hoạt bởi nhiều lý do, một trong số đó là tiêu đề của câu hỏi này.

Đã gặp lỗi nghiêm trọng 1236 từ chủ khi đọc dữ liệu từ nhật ký nhị phân: 'Không thể tìm thấy tên tệp nhật ký đầu tiên trong tệp chỉ mục nhật ký nhị phân'

Lỗi này xảy ra khi máy chủ nô lệ yêu cầu nhật ký nhị phân để sao chép không còn tồn tại trên máy chủ cơ sở dữ liệu chủ.

Vì vậy, nhiều kịch bản có thể gây ra điều này:

  • Máy chủ chính hết hạn nhật ký nhị phân thông qua biến hệ thống expire_logs_days (my.cnf nếu bạn đặtexpire_logs_days binlog cũ hết hạn tự động và bị xóa; Khi MySQL mở tệp binlog mới, nó sẽ kiểm tra các binlog cũ hơn và xóa bất kỳ giá trị nào cũ hơn giá trị của expire_logs_days)
  • Ai đó đã xóa thủ công nhật ký nhị phân từ chủ qua PURGE BINARY LOGS lệnh hoặc thông quarm -f lệnh
  • Bạn có một số cronjoblưu trữ nhật ký nhị phân cũ hơn để yêu cầu không gian đĩa

Để giải quyết vấn đề này, chỉ có sạch giải pháp tôi có thể nghĩ đến là tạo lại máy chủ nô lệ từ bản sao lưu máy chủ chính hoặc từ nô lệ khác trong cấu trúc liên kết sao chép.

Tham khảo: sao chép mysql có lỗi nghiêm trọng

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.