MariaDB

Mike54

Mike54

Member
Is anyone using MariaDB? What prompted you to use it and how well is it working for you? Is it really the drop-in replacement it seems to be?

I've been trying to learn a bit more about both MariaDB and Percona, but it seems MariaDB might be better suited for InnoDB, which could make it a natural for my XenForo forum. Everything I've read about MariaDB is almost too good to be true, so I'm interested to hear your thoughts on it.

I'm still running MySQL 5.1.68, so what would be the best way to get to MariaDB 5.5? Upgrade MySQL to 5.5 first, or roll it over to MariaDB 5.3 and then upgrade MariaDB from there?
 
KH-Jonathan said:
You can't go wrong with MariaDB. ... You won't regret it.
Click to expand...
I was afraid you would say that. ;)

Can you talk to me a bit about optimizing MariaDB? Will mysqltuner still be a good tool to use with MariaDB? What about variables in /etc/my.cnf, are those still going to be part and parcel of tuning up MariaDB?

EDIT - Another question. What is the better method, using XtraDB or the InnoDB plugin? Bearing in mind I have a few WordPress blogs and one Invision forum running on my sites, as well as the XenForo forum.
 
It's very similar to optimizing MySQL. Actually pretty much identical. MySQLTuner will still work wonderfully.

In MariaDB, InnoDB = XtraDB. XtraDB is built in.
 
Drat! Jonathon, can you no see what you are doing is akin to putting a needle in a junkie's hands? ;)

In all honesty, my sites all run incredibly fast. But I am always looking to find just a little more performance.

I appreciate your prompt reply to my PC and I'll get a ticket to sales for the move.
 
Hello Mike,

Did you make the transition to MariaDB?

We run all our servers with MariaDB 5.5.29 and when we did the switch, an improvment between 2 to 12% was recorded by our Munin monitoring system without tweaking anything in MariaDB. No account was down or suffered an outage during the switch between both SQL services.

On cPanel.net, they have a tutorial that is explaining step-by-step to switch between MySQL and MariaDB.

http://blog.cpanel.net/mysql-mariadb/
 
Jean,

Thanks for posting that wonderful tutorial. That's indeed the steps we use to transition clients to MariaDB :)
 
Hello Jean.
Jean Boudreau said:
Did you make the transition to MariaDB?
Click to expand...
Yes, but I made a very disappointing account change, at the same time. At the time of the change to MariaDB, I requested my account be moved to a VPS7 account. After the change, I have been living in WordPress Hell. I have several WordPress sites that all go down, every day, with the same fatal error, at random times of the day and for random periods of time. I cannot sort the problem, nor can the KH techs. They initially suggested it was either one of my plug-ins, or a combination of incompatible plug-ins that were causing the problem (in spite of the fact the sites had always run like Swiss watches on my old Hybrid account). So I spent several days, disabling and removing plug-ins, to see if I could find the problem. I even set up a WP site, straight out of the tin, with absolutely no add-ons, which still fell victim to the same error. Then KH suggested it was a problem with APC running on the server, in spite of the fact APC had also been running on my old Hybrid account.

It seems I am now down to just two possibilities. Migrating my WP sites over to Joomla, or exploring alternative hosting companies. I really have enjoyed these last 5 years with KH, but I also enjoy using WP and the idea of trying to start over on the Joomla platform is not very attractive to me.

MariaDB was certainly a move in the right direction, no question about that. As for the account upgrade downgrade to VPS7, I wish I had never made that decision.
 
Mike,

A move to VPS-7 should have in no way broken your WordPress sites. It was no different than any other package upgrade/downgrades you might have done in the past.

Can you send me over a ticket number to look at? I'll see if I can track something down.
 
Ticket 316902 and ticket 329996

I appreciate you looking into it, again. As mentioned above, I never had an issue with any of these sites, prior to the move. And I've had nothing but issues with them, since the move. There is only the one, common denominator. I've disabled plug-ins as recommended (even by yourself), which made no difference, other than to improve loading speeds. I've run the WP sites with zero plug-ins, even removing Akismet, to see if that could be causing the problems. Yet the sites continue to crash, on a daily basis.

At one point, it was suggested APC might be causing the problem, but I was using APC prior to the move. And logic says if APC was the culprit, all of the WP sites would go down, rather than just one or two. Very early this morning, all of the sites were loading, albeit slowly, whilst one site was down for at least 3.5 hours displaying the following error -

Fatal error: Call to undefined function _x() in /home/XXXXXX/public_html/wp-includes/taxonomy.php on line 432

After the 3.5 hours of downtime, the index page of the blog would then load, but attempting to view any other page would result in the above error. I cleared browser cache, several times, to no avail. I tried 4 other browsers and got the same result on all of them. Then, suddenly, the index page was gone again, for over 45 minutes. After that time, the site started working again, with no problems, whatsoever.

The problem with trying to sort the problem is the sites will crash at random times and be down for random times, so it is impossible to know for sure when any of them will be available and when they won't. One of the sites will typically crash at this time of day, but is currently working. It gets frustrating, for everyone, trying to troubleshoot intermittent problems.

I look forward to hearing from you.
 
Mike54 said:
Fatal error: Call to undefined function _x() in /home/XXXXXX/public_html/wp-includes/taxonomy.php on line 432
Click to expand...

Mike,

"Call to undefined function" type errors are directly indicative of a coding error in most cases. The only other reasons I could think of that would trigger this would be a file that can't be accessed which may contain these functions, a bad cache load, or something similar to that. 99% of the time it's a direct coding error.

Is it possible that this function is only needed in certain scenarios, and only those scenarios are throwing the errors, hence it looks to be intermittent? I've seen this quite frequently.
 
Jonathon,

I hear what you are saying about a coding error. But here is where I am left scratching my head.

The day before we made this account upgrade, all of my WordPress sites were running on WP 3.5.1. Most of them were configured alike, using the same plug-ins. And all of them were running smoothly, all day, every day.

The day of the account upgrade, with no changes being made to any of them, the WP sites started displaying extremely slow load times and started showing the above error, every day. When I say no changes were made, I mean all the sites were still running WP 3.5.1, with all of the same plug-ins.

How can a coding error come into play, when none of the code was changed?

It was suggested a couple of the plug-ins were out-dated and causing the problem, so I upgraded them, only to see the same results.

It was suggested one or more of the plug-ins was simply incompatible with the others (even though the alleged incompatibility had never manifested itself prior to the upgrade), so I disabled all of the plug-ins, only to see the same results. I started adding plug-ins, one at a time, only to see the same results. I switched to the standard WP theme, thinking Thesis might be causing the problems, only to see the same results.

I am aware WP can be a little awkward with the removal of plug-ins, so in early-June, I wiped one of my WP sites clean. I deleted all of the site files, deleted the database and started with a fresh installation. Only to see the same results.

When WP 3.5.2 was released in late-June, I upgraded to it, in the hope I would be rid of the problem. So there was a code change made at that time, but all of the sites continue to load slowly and crashing, every day.

I set up another test WP site, using zero plug-ins, only to see the same results.

Very early, on the morning of 4 August, I upgraded one site to WP 3.6. I successfully ran the upgrade script and when trying to access the control panel, after the software upgrade, the site crashed. Approximately 4 hours later, it was back up and running, with no changes made on this end.

Yes, I agree the error seems to indicate some kind of a coding problem. But I am not talking about a piece of custom software, written with questionable coding, I am talking about bog-standard WordPress. How many millions of sites use the same code, with zero problems? Which ultimately brings me right back to what I said, earlier - The day before we made this account upgrade, all of my WordPress sites were running on WP 3.5.1. Most of them were configured alike, using the same plug-ins. And all of them were running smoothly, all day, every day.

All I know to do is to apply top-down logic to all of this. The result to that makes no sense, but when there were no other changes made, what else can it be?
 
Mike,

I can certainly understand your logic. I'd be thinking the same way in your shoes.

Here's a theory that comes to mind - I see that you are running APC, Memcached, and eAccelerator. I'd recommend disabling two of these and keeping only one. It's very possible for the 3 caches to be interfering with one another (especially eAccelerator and APC, which are both opcode caches) and causing weird things to happen.

Are there any URLs where you can consistently replicate the issue? I've just poked through some of your sites and I can't seem to get it to throw an error. The caches interfering with one another would certainly explain the intermittent part of this.
 
Jonathon,

I was unaware eAccelerator was still running on the machine. Take a look at ticket 202153, from back on 2 December 2011. At 4:53 PM, Victor clearly stated, "We have disabled eAccelerator, ionCube Loader and Zend Optimizer in your server..."

Yes, eAccelerator needs to be gone and away. Is it possible that was somehow re-enabled during the account change? I can see where it could easily have been banging heads with APC and causing something unusual to happen. By all means, dump off eAccelerator, but I do want to continue with APC and Memcached.

I wish I could give you a URL with consistent replication, but it is random as it could be. Although you catching eAccelerator still running is giving me some renewed hope. <he says with his fingers crossed>
 
@KH-Jonathan , I will admit to only taking shallow breaths, but I am breathing again. I am cautiously saying I think removing eAccelerator has fixed the problem. I've been holding my breath, ever since it was removed. Obviously, no one can be checking multiple sites, every minute of every day, but I have been watching as closely as possible and I have not seen any of the WP sites throwing the error. I am almost ready to empty my pockets of these lucky pennies, horseshoes and rabbit's feet. I just hope I am not jinxing myself with this post. :D

Thank you for taking another look at things, because I think you picked up on what everyone else was missing.

Now, my biggest problem is envying @Azhria Lilu and her shiny-new SSD VPS. ;)
 
You must log in or register to reply here.
Top