With Postgres, there exists the ability to read the WAL (transaction log) byte code and transform it into JSON. Thus having say a GoLang process read it and execute events. Thereby having a real-time process.
Does a transaction log / replication log / something that can be readable exist?
We have a transaction log, but if I am not wrong, it’s not readable by other third party tools at the moment. It’s only for MemSQL internally to use. But providing a transaction log that’s compliant with other tools is something many customers have asked for, so we are definitely aware of the need.
Many thanks for following up. Totally understood where MmSQL is at.
That said, if at a minimum a transaction log from the master to a single file in /var/lib/[master id]/data/logs where its readable by the command line would be awesome. Also having an option to either have the transaction log grow, or truncate to every Xkb or Xmb size.
I’m sure you would hit a certain requirement % with the release of this functionality.
Memsql 7.0 can select into Kafka. Even though it’s not the change data capture feature lots of customers are requesting you can use it to stream data out from stored procedures or pipelines.
Whilst I’m sure others would welcome that. Personally I find this next to useless for my use case and please note that some customers do not use Kafka because it creates a lot of overhead, for many use cases its utter overkill and is akin to a black box.
As elon musk says, if it’s tight its right, if its long its wrong. When I look at infrastructure the simpliest solution is always the right one. Using over engineered software from the apache foundation will always get you into trouble!
Many thanks for replying, especially on a Saturday. Have a good one
At a minimum I envision the stream to go to a background process.
But if there are options available. There should be a way of pushing to a message queue like nats.io. I’m sure others would want zeromq, rabbitmq, kafka, etc. That would then allow for multiple background processes waiting. Which would also solve redundancy issues.
So in my case it would be a golang executable reading the stream. Which contains logic that depending on what happens, it would then create another job to execute a process or send something to the FE.
Having this ability makes the process fully reactive. Rather than having another golang executable hitting a table every second and checking to see if conditions are met. Which is something I’m actually doing now for my job queue ://
The more I think about it. Having a stream is the holy grail for me lol. There’s so much that I could do with it!
Not too much new to report on our end at this point. The feature is nearing the top the of the pile, but we don’t have a firm date yet on when work will start on it.