kafkaクラスタ内の1台の再起動後に自動的に問題の調査を停止する
3678 ワード
起因:
kibanaデータはデータが欠落していることを示しており、チェックしたところfilebeatsが書き込めないことが分かった.kafkaマシンにログインすると、クラスタ内の1番ノードleaderが-1であることが判明し、これまでの経験によると、原因は1番マシンkafkaとクラスタの通信異常であり、再起動後に問題を解決することができる.この場合のデータ損失の問題は、kafkaクラスタが-1のノードにデータを書き込むかどうかはテストされていません.コマンドを使用してtopicコピーの状況を表示します.
この時点で1号機プロセスが正常に動作していることを確認し、1号機kafkaプロセスを殺した後、
コマンドを再起動します.結局1分後にkafkaが起きていないことに気づいた.
問題の分析:
kafkaServerを表示します.outログ、最終レコードが次のように表示されます.
ログの解析を試みる:kafkaは自動的にshutdownし、内部エラーの可能性があります.グローバル検索大文字と小文字が厳密に一致する「ERROR」(上のコードセグメントのINFO列に対応)エラーの原因を発見する:
すなわち、既存のreplicationデータはshutdownから落ちた1号機のデータよりも約5 W少ないデータであり、このクラスタで問題が発生したpartitionsのデータ量は大きくないため、1、kafkaは1号機brokerがクラスタに加入できない場合でもデータ書き込みを処理する2、kafkaは1号機が利用できない場合に期限切れのデータをクリーンアップし、既存のデータが既存のデータより少ない3、kafkaが主に用意したデータの同期が一致しない、Replication同期データがleaderに遅れている場合、現在の機械圧力と正常な運転中にleaderが-1の場合を考慮して、ネットワークの変動やその他の原因によるデータ同期遅れの問題は排除されない.
問題検証:問題1:kakfa内のtopicパーティションを表示する場合はzookeeperで表示され、生産者がデータを生産する場合はkafkaを通過する必要はありません
解決方法:この方法は内topicが多すぎる場合には推奨されず、問題の3つの解決方法を直接参照することができ、同期して書き込まない場合もデータ損失の問題があります.zookeeperでkafka topic leaderが-1の解決方法を表示します:zookeeperに入ります:
対応するtopicのパーティションおよびleaderの状況を表示します.
手動でリーダー値を指定するには、次の手順に従います.
set/brokers/topics/R*/partitions/1/state {"controller_epoch":46,"leader":1004,"version":1,"leader_epoch":10,"isr":[1004]}
30 Sを待って、topic状態が回復するかどうかを確認します.
問題3:kafkaはクラスタの読み書きであり、brokerが-1の間も正常に書き込みサービスを提供し、データが同期しない可能性がある.この場合、マルチ書き込みデータを削除した後、サーバを再起動してデータ同期が完了するのを待つだけでよい.データに対する要求が高い場合は、まずデータをバックアップし、それからデータを削除し、サービス同期データを再起動し、最後にバックアップデータの新しいデータを手動で分析する必要があります.
kibanaデータはデータが欠落していることを示しており、チェックしたところfilebeatsが書き込めないことが分かった.kafkaマシンにログインすると、クラスタ内の1番ノードleaderが-1であることが判明し、これまでの経験によると、原因は1番マシンkafkaとクラスタの通信異常であり、再起動後に問題を解決することができる.この場合のデータ損失の問題は、kafkaクラスタが-1のノードにデータを書き込むかどうかはテストされていません.コマンドを使用してtopicコピーの状況を表示します.
/opt/kafka_2.11-1.1.1/bin/kafka-topics.sh --zookeeper ip1:2181,ip2:2181,ip3:2181 --describe --topic xxxxx
この時点で1号機プロセスが正常に動作していることを確認し、1号機kafkaプロセスを殺した後、
./bin/kafka-server-start.sh -daemon ./config/server.properties
コマンドを再起動します.結局1分後にkafkaが起きていないことに気づいた.
問題の分析:
kafkaServerを表示します.outログ、最終レコードが次のように表示されます.
[2019-07-03 09:26:34,580] INFO [ThrottledRequestReaper-Fetch]: Shutting down (kafka.server.ClientQuotaManager$ThrottledRequestReaper)
[2019-07-03 09:26:34,857] INFO [ThrottledRequestReaper-Fetch]: Stopped (kafka.server.ClientQuotaManager$ThrottledRequestReaper)
[2019-07-03 09:26:34,857] INFO [ThrottledRequestReaper-Fetch]: Shutdown completed (kafka.server.ClientQuotaManager$ThrottledRequestReaper)
[2019-07-03 09:26:34,857] INFO [ThrottledRequestReaper-Produce]: Shutting down (kafka.server.ClientQuotaManager$ThrottledRequestReaper)
[2019-07-03 09:26:35,857] INFO [ThrottledRequestReaper-Produce]: Stopped (kafka.server.ClientQuotaManager$ThrottledRequestReaper)
[2019-07-03 09:26:35,857] INFO [ThrottledRequestReaper-Produce]: Shutdown completed (kafka.server.ClientQuotaManager$ThrottledRequestReaper)
[2019-07-03 09:26:35,857] INFO [ThrottledRequestReaper-Request]: Shutting down (kafka.server.ClientQuotaManager$ThrottledRequestReaper)
[2019-07-03 09:26:35,858] INFO [ThrottledRequestReaper-Request]: Stopped (kafka.server.ClientQuotaManager$ThrottledRequestReaper)
[2019-07-03 09:26:35,858] INFO [ThrottledRequestReaper-Request]: Shutdown completed (kafka.server.ClientQuotaManager$ThrottledRequestReaper)
[2019-07-03 09:26:35,860] INFO [SocketServer brokerId=0] Shutting down socket server (kafka.network.SocketServer)
[2019-07-03 09:26:35,887] INFO [SocketServer brokerId=0] Shutdown completed (kafka.network.SocketServer)
[2019-07-03 09:26:35,895] INFO [KafkaServer id=0] shut down completed (kafka.server.KafkaServer)
ログの解析を試みる:kafkaは自動的にshutdownし、内部エラーの可能性があります.グローバル検索大文字と小文字が厳密に一致する「ERROR」(上のコードセグメントのINFO列に対応)エラーの原因を発見する:
[2019-07-03 09:26:25,058] ERROR [ReplicaFetcher replicaId=0, leaderId=2, fetcherId=0] Exiting because log truncation is not allowed for partition xxx-xxx-2, current leader's latest offset 8260512 is less than replica's latest offset 8314390 (kafka.server.ReplicaFetcherThread)
すなわち、既存のreplicationデータはshutdownから落ちた1号機のデータよりも約5 W少ないデータであり、このクラスタで問題が発生したpartitionsのデータ量は大きくないため、1、kafkaは1号機brokerがクラスタに加入できない場合でもデータ書き込みを処理する2、kafkaは1号機が利用できない場合に期限切れのデータをクリーンアップし、既存のデータが既存のデータより少ない3、kafkaが主に用意したデータの同期が一致しない、Replication同期データがleaderに遅れている場合、現在の機械圧力と正常な運転中にleaderが-1の場合を考慮して、ネットワークの変動やその他の原因によるデータ同期遅れの問題は排除されない.
問題検証:問題1:kakfa内のtopicパーティションを表示する場合はzookeeperで表示され、生産者がデータを生産する場合はkafkaを通過する必要はありません
解決方法:この方法は内topicが多すぎる場合には推奨されず、問題の3つの解決方法を直接参照することができ、同期して書き込まない場合もデータ損失の問題があります.zookeeperでkafka topic leaderが-1の解決方法を表示します:zookeeperに入ります:
対応するtopicのパーティションおよびleaderの状況を表示します.
手動でリーダー値を指定するには、次の手順に従います.
set/brokers/topics/R*/partitions/1/state {"controller_epoch":46,"leader":1004,"version":1,"leader_epoch":10,"isr":[1004]}
30 Sを待って、topic状態が回復するかどうかを確認します.
問題3:kafkaはクラスタの読み書きであり、brokerが-1の間も正常に書き込みサービスを提供し、データが同期しない可能性がある.この場合、マルチ書き込みデータを削除した後、サーバを再起動してデータ同期が完了するのを待つだけでよい.データに対する要求が高い場合は、まずデータをバックアップし、それからデータを削除し、サービス同期データを再起動し、最後にバックアップデータの新しいデータを手動で分析する必要があります.