I think the EU is affected as well by this. If there was any foreign region that needs access to the police services of the UK, I would bet the neighboring EU countries would be at the top of the list.
Configuring innodb file per table was pretty common years ago when I last worked with MySQL. I thought the entire file gets deleted if you nuke the table. This would be for the default config with a single innodb file right? To remove some tombstones.
I blindly clicked this expecting an article about the matter. Was kinda surprised to be given a live demonstration. I can reach nhs.uk fine.
Edit: searching Google, there are recent reports that make me feel like this is their response to being too incompetent to process cyber crime reports. I’m genuinely curious if someone unilaterally decided that people not physically in the uk don’t matter.
I won't be following up further. I've shared all I have to share on this topic. On a personal level, I'm actually disappointed in how you take to critical feedback about your product and don't seem to be interested in understanding the problem domain you're developing for.
This seems like a lack of knowledge issue. The problems with rqlite are inherit in it's design as I've already articulated. You can literally start reading jepsen analyses right now and understand it if you don't already: https://jepsen.io/analyses
The qualifier here is for /my/ use cases. However I couldn't recommend rqlite over better options at the level of scale that it can fill.
One of the problems is if you're working with developers, the log replication contents is the queries, instead of the sqlite WAL like in dqlite. I know this is a work around to integrate mattn/sqlite3, but it's untenable in enterprise applications where developers are going to just think "oh, I can do sqlite stuff!". This is a footgun that someone will inevitably trigger at some point if rqlite is in their infrastructure for anything substantial. In enterprise, it's plainly untenable.
Another issue is if I want to architect a system around rqlite, it wont be "consistent" with rqlite alone. The client must operate the transaction and get feedback from the system, which you can not do with an HTTP API the way you've implemented it. There was a post today where you can observe that with the jetcd library against etcd. Furthermore to this point, you can't even design a consistent system around rqlite alone because you can't use it as a locking service. If I want locks, I end up deploying etcd, consul, or zookeeper anyways.
If I had to choose a distributed database with schema support right now for a small scale operation, it would probably be yugabyte or cockroachdb. They're simply better at doing what rqlite is trying to do.
At the end of the day, the type of people needing to do data replication also need to distribute their data. They need a more robust design and better safety guarantees than rqlite can offer today. This is literally the reason one of my own projects has been in the prototyping stage for nearly 10 years now. If building a reliable database was as easy as integrating sqlite with a raft library, I would have shipped nearly 10 years ago. Unfortunately, I'm still testing non-conventional implementations to guarantee safety before I go sharing something that people are going to put their valuable data into.
To simply say I'm "ruling out a piece of software because it doesn't scale horizontally" is incorrect. The software lacks designs and features required for the audience you probably want to use it.
Hopefully you find my thoughts helpful in understanding where I'm coming from with the context I've shared.
Having looked at the test suite already, I know enough to know that I don't understand it well enough to be that guy to do this. It's for this reason, I'm personally going to pull out the popcorn and see what happens over the next few weeks.
Every time I've looked at rqlite, it just falls short features-wise in what I would want to do with it. A single raft group does not scale horizontally, so to me rqlite is a toy rather than a tool worth using (because someone might mistake the toy as production grade software).
Your posts are something I have in my bookmarks and reference regularly as I continue to build my own distributed data system. Thanks for continuing to test and report on these issues. These posts have clarified a lot of details about the consistency guarantees of these systems that I really couldn’t discern from their own documentation. The knowledge is invaluable with how developers lean towards just trusting the system they consume to be correct.
Depending on what you’re using these tools for. If you want a locking manager and some meta data storage to help your distributed system maintain state, etcd is better for the job than rqlite for that. It’s a better zookeeper. With etcd you can hold a lock and defer unlocking if the connection is disrupted. Rqlite is not a good option for this.
From what I’ve seen, the problems that have cropped up with open source software doesn’t seem to be corporate use, but instead companies that operate at scale without doing much to improve the software they are making bank on. AGPLv2 bridges that gap imo. What I’ve noticed is companies that want to use software without the requirements imposed will pay for custom licenses so they can make changes without having to share back. The money from commercial licenses ends up benefiting the projects using the license. Grafana and Minio seem to be doing great in this model.
This is pretty much a repeat of Richard Stallman’s experiences that led him to founding what would become GNU. Also open source really isn’t just being able to view the code, but the ability to modify, use, and redistribute freely.
The article is pay walled. Seems like this would be the fault of the airlines though. There is a reason to be distributed between different geographic areas.
Not sure if anyone else would have an interest in this, but personally I find dealing with SQL in Go worse than just dealing with HTTP APIs. This is the first step in an ecosystem I'm putting together to rapidly prototype products to run in Kubernetes clusters.