kafka新的生產者無法更新元數據後，其中一個經紀人關閉

我有一個kafka環境有2個經紀人和1個動物園管理員。kafka新的生產者無法更新元數據後，其中一個經紀人關閉

雖然我試圖向卡夫卡發送消息，但是如果我停止代理1（這是領導者之一），則客戶停止生成消息並給我以下錯誤，儘管代理2被選爲該主題的新領導者和partions。

org.apache.kafka.common.errors.TimeoutException：失敗後60000毫秒更新元數據。

經過10分鐘後，由於券商2是新的領導我所期望的生產商將數據發送到代理程序2，但它繼續通過上面的例外給予失敗。儘管生產者的metadataExpireMs爲300000，lastRefreshMs和lastSuccessfullRefreshMs仍然相同。

我在生產者端使用kafka new Producer實現。

看來，當生產開始，它結合一個經紀人，如果該經紀人下降它甚至沒有試圖連接到另一個經紀人集羣。

但我的期望是，如果一個經紀人下山的時候，應該直接檢查元數據的另一個經紀人可用並將數據發送給他們。

順便說一下我的主題是4分，並有給予這種信息的情況下，它是有道理的2.複製因子。

配置參數。

{request.timeout.ms=30000, retry.backoff.ms=100, buffer.memory=33554432, ssl.truststore.password=null, batch.size=16384, ssl.keymanager.algorithm=SunX509, receive.buffer.bytes=32768, ssl.cipher.suites=null, ssl.key.password=null, sasl.kerberos.ticket.renew.jitter=0.05, ssl.provider=null, sasl.kerberos.service.name=null, max.in.flight.requests.per.connection=5, sasl.kerberos.ticket.renew.window.factor=0.8, bootstrap.servers=[10.201.83.166:9500, 10.201.83.167:9500], client.id=rest-interface, max.request.size=1048576, acks=1, linger.ms=0, sasl.kerberos.kinit.cmd=/usr/bin/kinit, ssl.enabled.protocols=[TLSv1.2, TLSv1.1, TLSv1], metadata.fetch.timeout.ms=60000, ssl.endpoint.identification.algorithm=null, ssl.keystore.location=null, value.serializer=class org.apache.kafka.common.serialization.ByteArraySerializer, ssl.truststore.location=null, ssl.keystore.password=null, key.serializer=class org.apache.kafka.common.serialization.ByteArraySerializer, block.on.buffer.full=false, metrics.sample.window.ms=30000, metadata.max.age.ms=300000, security.protocol=PLAINTEXT, ssl.protocol=TLS, sasl.kerberos.min.time.before.relogin=60000, timeout.ms=30000, connections.max.idle.ms=540000, ssl.trustmanager.algorithm=PKIX, metric.reporters=[], compression.type=none, ssl.truststore.type=JKS, max.block.ms=60000, retries=0, send.buffer.bytes=131072, partitioner.class=class org.apache.kafka.clients.producer.internals.DefaultPartitioner, reconnect.backoff.ms=50, metrics.num.samples=2, ssl.keystore.type=JKS}

使用案例：

1-開始BR1和BR2生成數據（組長是BR1）

2-停止BR2產生數據（精）

3-停止BR1（其意味着在羣組中沒有主動工作的經紀人在這個時候），然後開始BR2和生產數據（儘管失敗的領導者是BR2）

4-開始BR1生產數據（領導者仍然是BR2但數據被精細製造）

5-停止BR2（現在是BR1前導）

6-停止BR1（BR1仍然是領導者）

7-開始BR1產生的數據（消息被產生的細再次）

如果生產商將最新的成功數據發送給BR1，然後所有經紀人都關閉，但生產商希望BR1重新站起來，儘管BR2已經成爲新的領導者。這是預期的行爲嗎？

來源

2016-02-29 jit

您可以發佈您在製作者中使用的配置嗎？ – Nautilus

我所有的製作配置都是默認的kafka製作配置。 – jit

由於缺乏提供的配置，我只能給出一個教育猜測：您只在屬性中列出了一個經紀人：_metadata.broker.list_ – TobiSH

花了幾個小時後，我想出了卡夫卡在我的情況下的行爲。可能是這是一個錯誤，或者可能需要這樣做，原因在於引擎蓋下，但實際上，如果我會這樣做，我不會這樣做:)

當所有經紀人發生故障時，如果你只能起身一個經紀人，那麼這個經紀人必須是最後經紀人才能成功地製作消息。

比方說，你有5個經紀人; BR1，BR2，BR3，BR4和BR5。如果一切都結束了，並且如果最後一位經紀人是BR3（這是最後一位領導人），雖然您啓動了所有經紀人BR1，BR2，BR4和BR5，但除非您啓動BR3，否則將毫無意義。

來源

2016-03-02 09:20:08 jit

我相信行爲取決於'unclean.leader.election.enable'和'min.insync.replicas'的代理設置。如果一場不潔的領導人選舉被允許，那麼其他經紀人之一可以成爲新的領導人，即使最後一個經紀人仍然失敗，你也應該能夠發佈。看到這個演示文稿的所有權衡https://www.slideshare.net/gwenshap/kafka-reliability-when-it-absolutely-positively-has-to-be-there –

您需要增加重試次數。在你的情況下，你需要將它設置爲> = 5。

這是您的製作人知道您的羣集有新領導者的唯一途徑。

除此之外，請確保您的所有經紀都有您的分區副本。否則你不會獲得新的領導者。

來源

2017-09-08 22:57:27

kafka新的生產者無法更新元數據後，其中一個經紀人關閉

回答

相關問題