Hello,
Thanks for your question. I've posted my comment to the StackOverflow question.
I'd avoid adding it to the core package as some of Record formats
handles compressed inputs by themselves, like Avro.
http://apache-avro.679487.n3.nabble.com/read-a-compressed-avro-file-td3872899.html
Adding
Hi Dano,
Thanks for your recommendation. I'll surely keep that in mind.
>From your answer, I infer at least some of your data processing uses NiFi as
>the choreographer. In my case, we use NiFi just to move data around, so it
>performs a more limited role.
To give you some context: My goal is
Hello Márcio,
We've been running NiFi clusters for almost 3 years now at Looker on AWS.
We will be moving these over to GCP in the future. My main recommendation
is to ensure that you're using something like Ansible to help with the
deployment and configuration of the cluster. We use a lot of
So the CaptureChangeMySQL processor is designed to be configured as run on
Primary node? even my nifi is cluster mode.
Now I have many CaptureChangeMySQL processors, connecting to different
Mysql Server. If all run on the primary node, the primary node is too high
loaded.
Is there
CSV, JSON, and XML files all compress well and thus you often see them
stored in a compressed format. Actually, it's not feasible or simply
practical to first decompress the files and then process them into a
binary format.
How would I go about extending or modifying the
`AbstractRecordProcessor`
Hi,
If CaptureChangeMySQL is configured to run on all nodes, there will
duplicate events for sure.
However, in your case the exception is thrown for having same "Sever ID"
for all instances of the processor connecting to MySQL server.
I don't see any data loss due currecurrent execution.
