Member since
01-09-2014
283
Posts
70
Kudos Received
50
Solutions
My Accepted Solutions
Title | Views | Posted |
---|---|---|
1716 | 06-19-2019 07:50 AM | |
2741 | 05-01-2019 08:07 AM | |
2790 | 04-10-2019 08:49 AM | |
2705 | 03-20-2019 09:30 AM | |
2364 | 01-23-2019 10:58 AM |
11-22-2016
08:26 AM
What does the output of: kafka-topics --describe --zookeeper server1:2181 show? -pd
... View more
08-22-2016
09:28 AM
This line is missing the hdfs prefix: a1.sinks.snk-1.rollCount = 0 It should be: a1.sinks.snk-1.hdfs.rollCount = 0 Otherwise all your files will contain 10 events, which is the default hdfs.rollCount. -pd
... View more
08-10-2016
05:13 PM
3 Kudos
Cloudera guarantees backwards compatibility in our minor releases. Although you see the Solr major version staying the same, we continuously backport fixes and security patches and even minor features as long as they don't break backwards compatibility for our many 100s of production customers on Cloudera Search (i.e. Solr in CDH). Meanwhile, our search engineering team here at Cloudera, including many of the Solr committers (e.g. Yonik Seeley, Mark Miller, Wolfgang Hoschek, et al) are actively working on new major features and rearchitectural changes to improve scale, performance, etc - all the goodness of our commitment and investment in the community. The major changes in Solr 5 have broken a lot of previous behavior, it also comes with major changes that brings a lot of risk. We choose to not put our production customers at risk, while still moving upstream forward with innovation. Solr 6 is now out and maturing. This is where we think production maturity will evolve. Solr 6 will eventually land in a future major release, once production quality is there. And it will be amazing!! All the work of our team and the community will then be available for new innovative applications. Please stay tuned for updates on the progress of Solr 6 and please don't hesitate reaching out to me if you need a more in depth session on what will come. I'm eva (at) cloudera (dot) com.
... View more
08-09-2016
11:02 AM
1 Kudo
This is actually a logging regression issue, that was introduced in CDH5.7.0, but fixed in CDH5.7.1, and the messages are benign, but can fill up the logs quickly. The recommendation would be to upgrade to CDH5.7.1 or higher where this logging regression was fixed. Alternatively, you can suppress these INFO messages by adding the following to the"Solr Server Logging Advanced Configuration Snippet (Safety Valve) ": log4j.logger.org.apache.solr.servlet.SolrDispatchFilter=WARN -pd
... View more
08-08-2016
09:05 AM
What is the exact version of Cloudera Manager that you have installed? -pd
... View more
08-05-2016
01:34 PM
4 Kudos
For this partition: Topic: truckevent Partition: 0 Leader: -1 Replicas: 57 Isr: 57 Since you only have replication-factor of 1, you don't have another replica to bring up as the leader. In this instance, you can move the replica to a running broker, but you will have to enable unclean leader election, as that new replica isn't in the ISR for partition 0. You won't have any of the data that is in that partition, as it all resides on broker 57. If you can move that data to broker 58, you would preserve the messages in that partition. If you need to go that route, you would need to use the kafka-reassign-partitions command to take the single partition (truckevent partition 0 on broker 57) and move it to another broker. See the full documentation here [1] In this example, we are moving partition 0 for the testmove topic from broker 52 to 51 in this example: [root@host-1 ~]# kafka-topics --describe --topic testmove --zookeeper ${HOSTNAME}:2181
Topic:testmove PartitionCount:2 ReplicationFactor:2 Configs:
Topic: testmove Partition: 0 Leader: -1 Replicas: 52 Isr: 52
Topic: testmove Partition: 1 Leader: 50 Replicas: 50 Isr: 50 1. Create the topictomove.json file: echo '{"topics": [{"topic": "testmove"}], "version":1 }' > topictomove.json 2. generate the partitions to reassign using the --generate option: root@host-1 ~]# kafka-reassign-partitions --zookeeper ${HOSTNAME}:2181 --generate --broker-list 51,50 --topics-to-move-json-file topictomove.json
Current partition replica assignment
{"version":1,"partitions":[{"topic":"testmove","partition":0,"replicas":[52]},{"topic":"testmove","partition":1,"replicas":[50]}]}
Proposed partition reassignment configuration
{"version":1,"partitions":[{"topic":"testmove","partition":0,"replicas":[50]},{"topic":"testmove","partition":1,"replicas":[51]}]} 3. Take the output from the "Proposed partition reassignment configuration" and include just the partition you want to move, in a file called reassign.json. In this instance, we are moving partition0 from replica 52 to replica 51 so the broker id listed in the json file will be the new target: [root@host-1 ~]# cat reassign.json
{"version":1,"partitions":[{"topic":"testmove","partition":0,"replicas":[51]}]} 4. If possible, copy the partition folder from the invalid broker to the new broker. This will ensure the partition contains all the data on the new broker: rsync -ave ssh /var/local/kafka/data/testmove-0 broker51:/var/local/kafka/data/ 5. Use the --execute command to make the changes: [root@host-1 ~]# kafka-reassign-partitions --zookeeper ${HOSTNAME}:2181 --execute --reassignment-json-file reassign.json
Current partition replica assignment
{"version":1,"partitions":[{"topic":"testmove","partition":0,"replicas":[52]},{"topic":"testmove","partition":1,"replicas":[50]}]}
Save this to use as the --reassignment-json-file option during rollback
Successfully started reassignment of partitions {"version":1,"partitions":[{"topic":"testmove","partition":0,"replicas":[51]}]} 6. At this time, the new replica will show up, but its not in the ISR list, and it can't be elected leader: [root@host-1 ~]# kafka-topics --describe --topic testmove --zookeeper ${HOSTNAME}:2181
Topic:testmove PartitionCount:2 ReplicationFactor:2 Configs:
Topic: testmove Partition: 0 Leader: -1 Replicas: 51,52 Isr: 52
Topic: testmove Partition: 1 Leader: 50 Replicas: 50 Isr: 50 And in the logs on the new broker, you will see the following: 2016-08-05 10:45:17,119 ERROR state.change.logger: Broker 51 received LeaderAndIsrRequest with correlation id 126 from controller 50 epoch 4 for partition [testmove,0] but cannot become follower since the new leader -1 is unavailable. 7. You will have to enable unclean.leader.election.enable in Cloudera Manager for the Kafka service configuration, and restart the kafka service. The broker that is the active controller needs to be restarted with this flag enabled to properly allow the new leader to be elected, even though it is not in the ISR list. 7. The new replica is now shown as the new leader: [root@host-1 ~]# kafka-topics --describe --topic testmove --zookeeper ${HOSTNAME}:2181
Topic:testmove PartitionCount:2 ReplicationFactor:1 Configs:
Topic: testmove Partition: 0 Leader: 51 Replicas: 51 Isr: 51
Topic: testmove Partition: 1 Leader: 50 Replicas: 50 Isr: 50 8. Turn off unclean.leader.election.enable and restart the cluster to ensure you have the safeguard back in place. NOTE: If you had data in the old partition on replica that wouldn't start,unless you copy that data from the old broker (as noted in step 4,) you will lose messages that were on that partition. I would recommend adding more replicas per partition. If you had a replication factor of 2 or more, you could move the replica to another server using the kafka-reassign-partitions command without having to enable unclean leader election (replication would happen automatically from the leader), but in your case, you only have 1 replica per partition, so you must enable the unclean leader election. [1] https://cwiki.apache.org/confluence/display/KAFKA/Replication+tools#Replicationtools-6.ReassignPartitionsTool
... View more
07-14-2016
02:02 PM
1 Kudo
If you are using the exec source to tail a file, keep in mind that it is not a very reliable source. I would suggest using the taildir source (https://archive.cloudera.com/cdh5/cdh/5/flume-ng/FlumeUserGuide.html#taildir-source) to tail files reliably. -pd
... View more
07-06-2016
10:12 AM
We have recently discovered an issue with the way hue sends facet requests to solr, and this has been identified as a bug. A future release of hue will change the way distributed faceting is called. -pd
... View more
06-24-2016
08:34 AM
Your understanding is correct. You either need to ensure flume can write to that directory, or create a directory that flume owns and can write to. -pd
... View more
06-23-2016
01:04 PM
This was a logging issue in that specific version of CDH. You can either upgrade CDH, or add a logging safety valve for the flume service: log4j.logger.source.SpoolDirectorySource=WARN -pd
... View more