MariaDB MaxScale and Least-Problems

Hello to all on the world wide web this morning!

As some of you who know me may know, I have been working night and day to bring LinkShare to life. I've come closer then ever and I am very happy with how well it's come so far. Don't judge my front-end work, I was always a lot more of a logic kind of programmer then the artistic CSS fanatic.

First, as you can see here, we get a bit of a hub where we can create new items. Note: The Frozen message you see above has been the latest of my additions. With LinkShare, if a user has not paid or is suspended for reasons that are not related to legal matters, I wanted to opt to freeze the account, potentially adding the ability to export their items later without destroying their work.

From here, we still need to polish the modal that displays for uploading/creating content, but we can password protect the share, add tags, set it in a folder, track or not track usage, set expiration, and more.

This allows clients and customers to upload whatever content they wish to share with friends and family. If they need to send over a quick PDF that isn't needed for tomorrow, they can upload and set that expiration for tonight at 11:59 PM. Additionally, to prepare in the worst cases, I have also opted to salt and hash passwords to links. Humans are prone to re-using passwords (you shouldn't! go check out Proton Pass, it's free!), and to reduce the chance of feeding that cycle of linking certain passwords to user emails and such (profiling of sorts, being able to guess your account passwords from previous data leaks and platforms), I chose to salt and hash the passwords. It's not un-crackable, but should take a lot more time if someone wishes to do so.

Next, we have our Manage Links section, where we can modify existing links to move around in folders and tags, edit other attributes, and more. Images/videos will generate thumbnails in the future, allowing you to see not only the name of the content you uploaded, but also see which it might be - if you're the type to upload YTVID-FixingAComputer_Final_Final_v23_RealFinal_AfterEncodingFix_120FPS_RealFixForSure.mkv.mp4.

I'll save the other screenshots until things are finished up - there's lots more features and such I have added over time, but you don't show your hand all at once...

Great question, and to that - it provides knowledge and insight as to how we wish to scale out. Every issue, every night I scan through logs, every minute I use to debug what's wrong with something is a learning point. I believe to shame someone or some team for using something to learn from is a horrible idea - many out there believe "you shouldn't be doing this to learn from it!". And to some extent, yes that's true. But there are limitations to resources and you can never prepare for everything.

Running this with very limited resources right now, as much as I would love to have a separated testing environment, there's only so much that can be done. I've set us up in such a way that it'll be easier to do so in the future, setting testing and production branches with two different servers holding those pods, but even then that is only the code - not the database. It'll be useful though as we scale to understand and prevent ID clashing, ensuring that if two people somehow get ID 2571 for an object, everything doesn't discombobulate.

At this time, geo-replication remains stable and syncs almost under a second. I'd say that's something to be damn proud of. Other disaster recovery protocols are being implemented and tested, as we need other factors such as sites disconnecting/offline for extended periods (ISP disconnects, upstream failure, Cloudflare breaks an upstream route, etc). However, as with everything, it'll take time.

At the current moment, I am looking to prioritize anything with UUIDs rather then basic integer IDs. This should drastically reduce chances of such items such as two different people using ID 22 at the same time. But other factors and answers to those issues include:

• Site Disconnect
  • How do we handle this? Do we isolate a site and set it's DB servers to read-only until it connects with others? Do we set a quorum, similar to Proxmox where if Site A is only connected to one other server out of 8 we have, we freeze them until back online? How will we handle Anycast from there once this comes to life?
• Multi-Site Session Management
  • Our server provider does provide Anycast, which we will use for certain in the future. The only problem is that we will need servers placed in every datacenter they own, which will be a little pricey. Thus, this is for much later but still something to consider.
  • Do we call upon our firewalls or load balancers/proxies to close ports when isolating to prevent them from answering requests that they cannot handle at the moment?
• Server Provider Failure
  • Even the great ones have their issues at times (look at Amazon Web Services!). Thus, the question remains - do we hold servers in other secure providers as well as backup? What ISP(s) do they use? Will they clash if one fails (i.e. Provider 1 goes down, but Provider 2 uses the same ISP or routes, so redundancy is defunct).
  • Do we even look at this if our provider can achieve 99% or more uptime? Is it worth it to spend thousands of dollars a year to keep a server active in the one day out of 1000 days it goes down?
  • Will this same provider give the same protections? We need DDoS protection and safety from any problems, whether it's botnets or someone upset that we host content they don't agree with (i.e. Birds Aren't Real). Only when DMCA requests and government/federal legalities are involved will content be removed.
• "Act's of God" type disasters
  • Lord forbid we have a site go offline due to tornados, tsunamis, etc. What do we do then? Will our provider handle it if we're on Anycast? Do we need to take over?

There's lots more to ask and answer and I think that we will find the answers we need in due time. Until then, other matters will be tried and tested. We can't prepare for everything but we can do so to the fullest extent that we are allowed to.

This is a question I ask myself. At the current moment, we hold a few different datastore types. These include:

• Object Storage (We use MinIO, but think Amazon S3, BackBlaze B2, etc.)
• Redis (for session management and cache)
• MariaDB (for more "legacy" items and simple datastores)
• PostgreSQL (for more "advanced" applications that can't use mDB, such as Authentik)

As explained above, MariaDB is simple. We don't need to deal with as much on a simpler level, leaving less room to mess something up and cause a security risk or server failure. I may opt to look into other avenues, perhaps mirroring data between PostgreSQL and MariaDB, but this will double storage costs and require more database servers. We can move everything over to PostgreSQL as well, but then that also places us into almost the same spot. From my own experience, PostgreSQL may be a bit more stable and better for replication, but can still present issues in rare cases requiring replicas to be rebuilt more often.

MariaDB is also part of the foundation I learned from, with help from a good friend, which makes it easier for me to understand and work with. Granted, it's a skill issue for sure, but keeping it simple also helps a lot. You don't need a jackhammer to break a pebble in half. Can you? For sure. But then your time will be spent putting the pebble on a place you can break it with the jack hammer, you need more space and room to use it, you'll need a source of fuel (air compression, diesel, etc.), and depending on the size of the pebble/jackhammer, you'll probably atomize the pebble instead anyways. Thus - you should just use a regular hammer. You can simply place the pebble down in a spot you can swing a good amount, and have everything you need in seconds.

I'll save it for the next post, but MariaDB holds a certain place in my heart, the same way PHP and NodeJS do. They are the starting points in which led me to great things, inspiration, and more. Those who showed me how to use it, their code, ideas, brought me more inspiration and motivation to be creative with my work. And without creativity and motivation - well I wouldn't be here today.

So with that, I have to thank them for doing so. They know who they are, I won't name names, but thank you for giving me the knowledge and inspiration through the years :D

If you're interested in reaching me elsewhere, feel free to shoot me a message/tweet/email/etc: https://yeehawitsjake.com/other-socials/