Can you roll back? If you can, start planning for an migration to MySQL.
Unable to rollback I guess that’s it for 2 of my websites lol… Not sure I understand why both databases can’t be supported… Just use the “basics” of each languages without over complicating/over-optimizing things… Is it better to be “perfect” in the design or have both systems work? Because many people are probably in the same situation where they have to use MariaDB
Was the change to a “newsletter” table (I have never even sent a newsletter…) so important to make that change and break everything?
Can’t you create a clone of your server, and then restore an earlier snapshot? If you do that, you’ve got options.
It’s a lot more effort for a small dev team to support another database. They’ve always been upfront about MySQL tool. I only heeded their warning a few weeks ago, and I’m glad I switched. :smug:
I hope you get it sorted.
I could restore a snapshot but not willing to go through all this effort, because my other site running XenForo with 1.2 million posts would lose a few days of data.
BTW XenForo works “fine” with either MySQL or MariaDB as it is supposed to be “drop in support”.
I still don’t understand why both can’t work together if it is supposed to be drop in support… unless you are using some very very obscure options I don’t see why everything needs to break
That’s why I suggested a clone first; work on this, not your production instance.
That’s nice advice for someone running it as VM, but not so much help if you’re running on physical hardware.
The OP, who I was replying to, has a VM. IIRC you were able to perform a rollback. Nonetheless, snapshots are possible without a VM and so is a rollback strategy.
So when you are referring to snapshots, would you share a little more information or maybe link to the documentation if there is this topic covered?
This is OS-dependent, and going off-topic. Nonetheless, snapshots are available with LVM, btrfs
and zfs
. Likewise, a good backup strategy will help you roll-back. Same goes for MariaDB…mysqldump
, automysqlbackup
etc.
If you’re still up and running on MariaDB, now is the time to migrate to MySQL.
Thank you mjw. I wasn’t aware of LVM feature being able to do snapshots. This is a game-changer
I will hire someone to do the attempted migration of MariaDB to MySQL on my server and get Ghost working again. I can snapshot the server first, so even if the attempt is an epic fail, I can restore and my large XenForo site will not be impacted.
If interested please reply here or send me a direct message.
I have an older backup of my VM. But I would prefer to fix this problem until a offical solution is available. Is there a way to skip the errnous alter table command during start
alter table newsletters modify ...
manullay?. I didn’t use newsletter for my blog.
I can’t speak for the Ghost team, but note that MariaDB isn’t officially supported, so there is no guarantee that there will be a fix. Moreover, Ghost 5.0 will definitely introduce breaking changes for MariaDB users.
For continuity, all MariaDB users should be planning to migrate their Ghost database to MySQL.
Also seeing this issue upgrading from 4.44.0 to 4.47.1.
I won’t be using an Oracle product, so sounds like it’s time to migrate to another site platform.
I won’t be using an Oracle product, so sounds like it’s time to migrate to another site platform.
Yeah, seriously. I’m switching to WriteFreely which is written in Go, much cleaner, supports federation with ActivityPub, and has a more powerful theming engine in the works.
My requirements are pretty simple and I have no issues writing markdown, so I’ve already moved my two sites to Jekyll and the Minimal Mistakes theme. The jekyll_ghost_importer tool was quite useful.
Was the change to the “newsletter” db that broke this so critical for performance that it absolutely had to be done, and break all the compatibility? If stick to a more simple table schema/structure, I would think the drop in replacement DB would work as needed – no need to overcomplicate things. I realize that I didn’t write this software and may just be missing something about how it was “absolutely” needed to make whatever the change was, but can the Ghost team revisit if it was really imperative?
I mentioned this before-- I never even sent a newsletter before and never planned to, yet this crashed everything for me. Could there at least be an option added to only do the “upgrade” for people that use newsletters? It doesn’t make sense to break a lot of sites when people don’t sent or use newsletters
Still Ghost is not compatible with MariaDB.
We were moving our recommended environment from MySQL5 to MySQL8 regardless, nothing to do with newsletters.
Ghost is a small team, so we make Ghost work according to a single recommended/supported environment, which is tested and documented in detail.
If you choose to use a different environment to what is documented and recommended, that’s fine, but your mileage may vary as a result.
For specific issues with MariaDB and Knex - the place to raise/discuss/resolve that is on the Knex repository or community. We are not the maintainers of Knex: