エラー1236-「バイナリログインデックスファイルで最初のログファイル名が見つかりませんでした」


10

私たちのセットアップ:

  • マスター:MariaDB 10.0.21
  • スレーブ:MariaDB 10.0.17

レプリケーションは最近まで正常に機能しており、その時点でスレーブのDBをダンプから復元する必要がありました。必要なすべての手順を実行しました。マスターのDBをダンプし、ダンプをスレーブに転送し、古いDBをドロップし、ダンプを実行してDBを復元し、適切なCHANGE MASTERコマンドを実行し、最後にを実行しましたSTART SLAVE

エラーが表示されます: Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'

スレーブがマスターから必要とする最初のログファイルはmysql-bin.000289です。これがマスター上にあることがわかります: ここに画像の説明を入力してください

マスターのバイナリログインデックスに、このログファイルのエントリがあるように見えることもわかります。 ここに画像の説明を入力してください

それでもレプリケーションは機能していません-同じエラーが発生し続けます。アイデアが足りません-次に何を確認すればよいですか?


更新:SHOW SLAVE STATUS\G要求通りの出力:

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)

追加で要求される情報:

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 (抜粋):

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

編集:Postion 342は存在するようです:

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

また、マスターバージョンはスレーブバージョンより少し新しいので注意してください。スレーブのバージョンはより高くなる可能性がありますが(間違いなくすべてのコマンド/機能/機能を理解するため)、マスターがより新しい場合は、スレーブが聞いたことのないものを呼び出す可能性があります。このようなマイナーなリビジョンの違いでは発生しないと思いますが、除外することはできず、間違いなく極端に難解であり、見つけるのが難しいでしょう。また、公式の行では、より新しいマスターはサポートされていません。
TheSatinKnight

回答:


6

自分が思っているマスターに接続していないようです。あなたが持っているように見えるマスター上のバイナリログごとに:

#160519 3:28:59 サーバーID 5

しかし、SHOW SLAVE STATUSに従って、次のように表示されます。

         Master_Server_Id: 3

さらに、ローカルホストに接続しているようですが、マスター/スレーブが異なるホストにあることを暗示しています:

              Master_Host: 127.0.0.1

1
SSHトンネリング(autosshを使用)を使用して、リモートマスターをローカルで公開してい127.0.0.1:3305ます。私はMaster_Server_Idにも気づきましたが、それは別のマスターを使用していた昔の名残であると思いました。SHOW SLAVE STATUSレプリケーションが完全に再確立されたら、の値が更新されることを期待していました。とにかく、これは素晴らしい提案です。私たちが実際に正しいマスターに接続していることをトリプルチェックします!
rinogo 2016年

1
私を正しい方向に向けてくれてありがとう!実際、私たちは間違ったマスターに接続していました。私はそれを確認しましたtelnet 127.0.0.1:3305-レポートされたMySQLのバージョンが古いマスターのバージョンと一致していることがわかりました。問題の根本は、ネットワーク上のいくつかのDNSの癖によるものと思われます-db.domain.comに接続するように構成されていたにもかかわらず、autossh接続がdomain.comに誤って確立されたようです。本当にありがとうございました。
rinogo

8

他のすべてが失敗した場合は、スレーブをリセットしてレプリケーションを再開する必要がある場合があります。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は、別の答えが正しかった(そして、彼らは間違ったインスタンスに接続していた)とコメントしました。
ypercubeᵀᴹ

3
@yper-trollᵀᴹ-はい、ただしStackexchangeの半分のポイントは質問のアーカイブにあります。これは、同じ問題を抱えている他のユーザーを検索するGoogle検索の上部に必ず表示されます。私もまったく同じ問題を抱えていましたが、これが解決策でした(特に、他のほとんどのページには同じ他の回答しか表示されないため、文字通り何時間もかけて解決に費やしたためです)。他の「間違った」回答に2つの賛成票があるという事実は、これを証明しています。
アンディビバリー

はい、公正なポイントです。これ(提案)が他のすべてが失敗したときに(そしてそのように明確にマークされているときに)使用されることを意図している限り、問題ありません。それが私がコメントしただけで、反対票を投じなかった理由です。
ypercubeᵀᴹ

1
この答えは、他のアドバイスがどれも当てはまらないときに機能しました。(私は既存の現在のbinlogを使用して作業していたか、マスターが適切に構成されていたなど)。オプションは上記でより目立つように述べられるべきです。
JDボールドウィン、

3

エラーメッセージが答えです。

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.000278は表示されません。

バイナリログがローテーションしない限り、mysql-bin.indexの内容は間違っています。

の内容をmysql-bin.index現在存在するbinlogsファイルと比較し、それらが一致することを確認してください。マスターでこれを修正できます

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

その後、スレーブに移動して実行します

mysql> STOP SLAVE; START SLAVE;

試してみる !!!


こんにちは、ローランド!あなたの助けを本当にありがとう!残念ながら、私はまだ混乱しています。もしかしてmysql-bin.000288代わりにmysql-bin.000278?もしそうなら、mysql-bin.000288存在するようです。これでも問題は解決しますか?
rinogo 2016年

PURGE BINARY LOGS TO 'mysql-bin.000279';ログ279が存在しなくなったため(予期されていたとおり)、エラーが発生しました(ローテーションされていました)。PURGE BINARY LOGS TO 'mysql-bin.000288';正常に実行され、「288」までのすべてのバイナリログが削除されました。残念ながら、まだエラーが発生します。
rinogo

あなたの詳細な提案、Rolandoに感謝します!問題は、間違ったマスター(dba.stackexchange.com/a/140259/55530)に接続していたことです。
rinogo

2

更新:この回答は、一般的なエラー分類をカバーしています。OPの正確なクエリを最適に処理する方法に関するより具体的な回答については、この質問に対する他の回答を参照してください

最重要のレプリケーションエラーの1つです。致命的なエラー1236 が発生しました。複数の理由によって引き起こされる可能性があります。その1つがこの質問のタイトルです。

バイナリログからデータを読み取るときにマスターから致命的なエラー1236が発生しました:「バイナリログインデックスファイルで最初のログファイル名が見つかりませんでした」

このエラーは、スレーブサーバーがレプリケーションに必要なバイナリログがマスターデータベースサーバーに存在しない場合に発生します。

多くのシナリオがこれを引き起こす可能性があります:

  • マスターサーバーは、システム変数を介してバイナリログを期限切れにします expire_logs_daysexpire_logs_days古いbinlogs を設定するとmy.cnf が自動的に期限切れになり、削除されます。MySQLが新しいbinlogファイルを開くと、古いbinlogがチェックされ、expire_logs_daysの値より古いものはすべてパージされます)
  • 誰かがPURGE BINARY LOGSコマンドまたはrm -fコマンドを介してマスターからバイナリログを手動で削除しました
  • あなたはいくつか持っているcronjob請求のディスク容量にどのアーカイブ古いバイナリログを

この問題を解決するために考えられる唯一のクリーンな解決策は、マスターサーバーのバックアップから、またはレプリケーショントポロジの他のスレーブからスレーブサーバーを再作成することです。

参照:MySQLレプリケーションで致命的なエラーが発生しました

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.