Wordpress on Vultr 768
-
@scottalanmiller said in Wordpress on Vultr 768:
@fuznutz04 said in Wordpress on Vultr 768:
@scottalanmiller said in Wordpress on Vultr 768:
I see, so this has been running for a while and only recently started having the problem? It seems like InnoDB is having an issue registering as an engine.
Yes, it was runnning fine for at least a week, then I abandoned it for a few months, and recently revisited and started having these issues.
Oh, you hurt it's feelings. That's a standard problem. Talk nice to it for a while.
Could be. It's not a HUGE deal, as I can just blow it away and start over, but it would be nice to find out what's going on for if/when it happens again
-
@fuznutz04 said in Wordpress on Vultr 768:
@scottalanmiller said in Wordpress on Vultr 768:
@fuznutz04 said in Wordpress on Vultr 768:
@scottalanmiller said in Wordpress on Vultr 768:
I see, so this has been running for a while and only recently started having the problem? It seems like InnoDB is having an issue registering as an engine.
Yes, it was runnning fine for at least a week, then I abandoned it for a few months, and recently revisited and started having these issues.
Oh, you hurt it's feelings. That's a standard problem. Talk nice to it for a while.
Could be. It's not a HUGE deal, as I can just blow it away and start over, but it would be nice to find out what's going on for if/when it happens again
Agreed. Since it is not mission critical, start with updates if those have not been run. 99% sure that that will not do anything, but you know, worth the test.
-
@scottalanmiller Yeah, that didn't fix it. I'll just start over. I recall discussion on here previously that the "one click" installs of Wordpress on Vultr are not recommended. I couldn't remember (or find the discussion) why this was the opinion...
-
Have you checked to see if these files exist and are correct size? Have you checked the .cnf file
InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytes
InnoDB: than specified in the .cnf file 0 8388608 bytes!Check your cnf file to see that it is correct. Rename/move ib_logfile0, ib_logfile1 (they'll get recreated when the service starts again)
-
@momurda said in Wordpress on Vultr 768:
Have you checked to see if these files exist and are correct size? Have you checked the .cnf file
InnoDB: Error: log file ./ib_logfile0 is of different size 0 5242880 bytes
InnoDB: than specified in the .cnf file 0 8388608 bytes!Check your cnf file to see that it is correct. Rename/move ib_logfile0, ib_logfile1 (they'll get recreated when the service starts again)
I renamed and started the service again, and the files were re-created. The site is online for a few seconds then crashes again. I'm not seeing any configuration file other than /etc/my.cnf, and the file only has a few lines of code in it.
[mysqld] datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock # Disabling symbolic-links is recommended to prevent assorted security risks symbolic-links=0 # Settings user and group are ignored when systemd is used. # If you need to run mysqld under a different user or group, # customize your systemd unit file for mariadb according to the # instructions in http://fedoraproject.org/wiki/Systemd [mysqld_safe] log-error=/var/log/mariadb/mariadb.log pid-file=/var/run/mariadb/mariadb.pid # # include all files from the config directory # !includedir /etc/my.cnf.dThe files in /etc/my.cnf.d have almost nothing in them as well.
-
@fuznutz04 said in Wordpress on Vultr 768:
@scottalanmiller Yeah, that didn't fix it. I'll just start over. I recall discussion on here previously that the "one click" installs of Wordpress on Vultr are not recommended. I couldn't remember (or find the discussion) why this was the opinion...
That's correct, those are never recommended. Use the OS, not a third party system.
-
@fuznutz04
I think there should be a bit more lines in that file.
What size files are the recreated innodb files?
What is the contents of /var/log/mariadb/mariadb.log -
@momurda said in Wordpress on Vultr 768:
@fuznutz04
I think there should be a bit more lines in that file.
What size files are the recreated innodb files?
What is the contents of /var/log/mariadb/mariadb.log5242880 bytes is the size of the new files.
Seems like I'm in a time warp, as it is warning me that my sequence numbers are in the future!
161107 12:17:20 InnoDB: Waiting for the background threads to start 161107 12:17:20 InnoDB: Error: page 348 log sequence number 133743653 InnoDB: is in the future! Current system log sequence number 107618964. InnoDB: Your database may be corrupt or you may have copied the InnoDB InnoDB: tablespace but not the InnoDB log files. See InnoDB: http://dev.mysql.com/doc/refman/5.5/en/forcing-innodb-recovery.html InnoDB: for more information. 161107 12:17:21 mysqld_safe mysqld from pid file /var/run/mariadb/mariadb.pid endedSo following the directions to force innodb into recovery mode, the DB starts, but then the logs say this:
InnoDB: A new raw disk partition was initialized or InnoDB: innodb_force_recovery is on: we do not allow InnoDB: database modifications by the user. Shut down InnoDB: mysqld and edit my.cnf so that newraw is replaced InnoDB: with raw, and innodb_force_... is removed. InnoDB: A new raw disk partition was initialized or InnoDB: innodb_force_recovery is on: we do not allow InnoDB: database modifications by the user. Shut down InnoDB: mysqld and edit my.cnf so that newraw is replaced InnoDB: with raw, and innodb_force_... is removed. InnoDB: A new raw disk partition was initialized or InnoDB: innodb_force_recovery is on: we do not allow InnoDB: database modifications by the user. Shut down InnoDB: mysqld and edit my.cnf so that newraw is replaced InnoDB: with raw, and innodb_force_... is removed. 161107 12:34:37 mysqld_safe Number of processes running now: 0 161107 12:34:37 mysqld_safe mysqld restarted 161107 12:34:40 [Note] /usr/libexec/mysqld (mysqld 5.5.50-MariaDB) starting as process 11049 ... 161107 12:34:40 InnoDB: The InnoDB memory heap is disabled 161107 12:34:40 InnoDB: Mutexes and rw_locks use GCC atomic builtins 161107 12:34:40 InnoDB: Compressed tables use zlib 1.2.7 161107 12:34:40 InnoDB: Using Linux native AIO 161107 12:34:40 InnoDB: Initializing buffer pool, size = 128.0M InnoDB: mmap(137756672 bytes) failed; errno 12 161107 12:34:40 InnoDB: Completed initialization of buffer pool 161107 12:34:40 InnoDB: Fatal error: cannot allocate memory for the buffer pool 161107 12:34:40 [ERROR] Plugin 'InnoDB' init function returned error. 161107 12:34:40 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed. 161107 12:34:40 [ERROR] mysqld: Out of memory (Needed 128917504 bytes) 161107 12:34:40 [Note] Plugin 'FEEDBACK' is disabled. 161107 12:34:40 [ERROR] Unknown/unsupported storage engine: InnoDB 161107 12:34:40 [ERROR] Aborting -
Just a bit of browsing I find this. You do actually seem to be out of memory, try adding
performance_schema = offto the [mysqld] section of my.cnf
-
@momurda said in Wordpress on Vultr 768:
Just a bit of browsing I find this. You do actually seem to be out of memory, try adding
performance_schema = offto the [mysqld] section of my.cnf
No go. Same result, same errors
-
Oh look, I fixed it!
(throws hands up and reinstalls.) -
Just don't forget to feed it... water it... say nurturing things to it.
-
Ah I forgot you put it in recovery mode. Turning that off might have fixed it, but if youre going to NIFO then that is ok too. Also when doing the reinstall make sure your permissions are right.
-
Wait, it works now? Or you reinstalled? Or both?
-
@scottalanmiller said in Wordpress on Vultr 768:
Wait, it works now? Or you reinstalled? Or both?
Sounds like both.
-
Think he means he fixed it by 'throwing hands up' and reinstalling. DOes the reinstall work though?
-
I "fixed it" by reinstalling. Now I'm in the process of setting up LAMP and then Wordpress again.
-
@fuznutz04 said in Wordpress on Vultr 768:
I "fixed it" by reinstalling. Now I'm in the process of setting up LAMP and then Wordpress again.
Gotcha
-
It's the old "Take that!" & nuke it from orbit ploy. Works every time.
-
@dafyre Exactly. Didn't want to waste any more time on it, especially since it was still in testing/setup stages.
