MySQL service will not stay running - Master/Slave error?

Omeka Classic Troubleshooting
1

Hello Everyone,
I am attempting to troubleshoot a problem whereby Omeka (Classiv v 2.7.1) is unable to connect to the underlying database:

Omeka Database Error
No connection could be made because the target machine actively refused it.
Confirm that the information in your db.ini file is correct.

Everything is installed on a Windows 2012R2 server. Using the XAmpp Control Panel (v 3.2.4), I attempt to start the MySQL service which is off and after a few moments, the service stops by itself. Looking at mysql_error.log, I see the following error entries:

2020-08-05 15:55:07 7 [Warning] Neither --relay-log nor --relay-log-index were used; so replication may break when this MySQL server acts as a slave and has his hostname changed!! Please use ‘–log-basename=#’ or ‘–relay-log=mysql-relay-bin’ to avoid this problem.
2020-08-05 15:55:07 7 [ERROR] log 2020-08-05 13:27:58 7 [Note] Initialized Master_info from ‘master-2020@002d07@002d27@002012@003a01@003a12@00200@0020@005bnote@005d@0020reading@0020of@0020all@0020master_info@0020entries@0020succeeded@000d.info’
listed in the index, but failed to stat
2020-08-05 15:55:07 7 [ERROR] Error counting relay log space
2020-08-05 15:55:07 7 [ERROR] Initialized Master_info from ‘master-2020@002d07@002d27@002012@003a01@003a12@00200@0020@005bnote@005d@0020reading@0020of@0020all@0020master_info@0020entries@0020succeeded@000d.info’ failed
…

I tried to overlay the following files with corresponding original ones:

  • aria_log.00000001
  • aria_log_control
  • ibdata1
  • ibtmp1
  • ib_buffer_pool
  • ib_logfile0
  • ib_logfile1
  • multi-master.info
  • my.ini

and re-start the MySQL service. The service did re-start and stayed running. However errors were being generated in the log and Omeka seemed to think at that point that the database instance was brand new:

2020-08-18 11:45:10 0 [ERROR] InnoDB: Page [page id: space=0, page number=7] log sequence number 288046 is in the future! Current system log sequence number 140309.
2020-08-18 11:45:10 0 [ERROR] InnoDB: Your database may be corrupt or you may have copied the InnoDB tablespace but not the InnoDB log files. Please refer to https://mariadb.com/kb/en/library/innodb-recovery-modes/ for information about forcing recovery.
…

So I restored the files back to the current ones and again the MySQL service would not remain running more than a few seconds:

InnoDB: using atomic writes.
2020-09-01 11:01:50 0 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
2020-09-01 11:01:50 0 [Note] InnoDB: Uses event mutexes
2020-09-01 11:01:50 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
2020-09-01 11:01:50 0 [Note] InnoDB: Number of pools: 1
2020-09-01 11:01:50 0 [Note] InnoDB: Using SSE2 crc32 instructions
2020-09-01 11:01:50 0 [Note] InnoDB: Initializing buffer pool, total size = 16M, instances = 1, chunk size = 16M
2020-09-01 11:01:50 0 [Note] InnoDB: Completed initialization of buffer pool
2020-09-01 11:01:51 0 [Note] InnoDB: 128 out of 128 rollback segments are active.
2020-09-01 11:01:51 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2020-09-01 11:01:51 0 [Note] InnoDB: Setting file ‘C:\xampp\mysql\data\ibtmp1’ size to 12 MB. Physically writing the file full; Please wait …
2020-09-01 11:01:51 0 [Note] InnoDB: File ‘C:\xampp\mysql\data\ibtmp1’ size is now 12 MB.
2020-09-01 11:01:51 0 [Note] InnoDB: Waiting for purge to start
2020-09-01 11:01:51 0 [Note] InnoDB: 10.4.11 started; log sequence number 6880304; transaction id 19226
2020-09-01 11:01:51 0 [Note] InnoDB: Loading buffer pool(s) from C:\xampp\mysql\data\ib_buffer_pool
2020-09-01 11:01:51 0 [Note] Plugin ‘FEEDBACK’ is disabled.
2020-09-01 11:01:51 0 [Note] Server socket created on IP: ‘::’.

Please let me know if I need to provide more info to help with this issue. I would greatly appreciate any pointers or tips to help with getting our database back up and serving the installed Omeka instance.

Best Regards

2

Do you have backups, i.e. SQL dumps of the database, not the ibdata files? If you do the simplest option is probably to just completely blow away the existing database and just load in the dump. Obviously this only applies if you have a recent enough dump that you’re comfortable doing this.

You may also be able to make dumps if you don’t have them by using the recovery mode options the error message linked to: that’s generally the point of those, to get the server up and running just enough to dump out the existing data. Though I’m not sure where the “original” files you’re working with there are from, depending on that it might completely make sense that using them removes all your data.

Beyond that kind of general advice, deeper MariaDB/MySQL server troubleshooting is a little out of scope for these forums, as you’re really dealing with a database server issue and not an Omeka one.

3

Hi there - thank you very much for the quick help. Unfortunately I don’t have dump files but I think the idea of using recovery mode to create dump files is a great idea (and safe as well). The original files are the ones that came with Xampp: (in our environment: C:\xampp\mysql\backup).

I can try to use the MySQL Workbench to do this work and see what recovery options are there. My concern was that once the database is restored (hopefully minus the master/slave errors), then Omeka will be able to recognize it and run with it.

I’ll update the thread with developments.

Thanks!

4

Hi there,

I wanted to provide an update and hopefully get additional insight. I was unable to take dumps of the database because there was just no way to get the database up long enough to do so. I did make copies of the /data directory anyway with the .frm and .ibd files just in case. Then I re-installed MySQL 5.7 and created a new Omeka database . Following the Omeka instructions I set the charset to the indicated type and also created a user to have rights over the new database.

I then went to http://localhost:82/Omeka/install and filled in the system configuration details to set up the system and initialize the database. But now I get the following error:

Schema task failed on failed on table ‘omeka_options’ with Zend_Db_Statement_Mysqli_Exception: Mysqli prepare error: Table ‘omeka.omeka_options’ doesn’t exist

Looking at the /data directory, I see only 7 tables created:

  • omeka_collections
  • omeka_element_texts
  • omeka_elements
  • omeka_item_types
  • omeka_item_types_elements
  • omeka_processes
  • omeka_tags

Looking at the backup of the previous /data directory, it seems that quite a few tables do not get created by the Omeka initialization process. Is there a way I can manually trigger the process to get a full Omeka back-end?

5

Well, the installer should, obviously, be installing all of the tables. Is there anything in the PHP or MySQL error logs that might indicate what happened here? Maybe you’re running out of room on your disk that stores the database, or there’s some other problem at that kind of level?

You can “start over” on an install easily by just dropping the tables out of the database, which will trigger the installer again.

6

This topic was automatically closed after 250 days. New replies are no longer allowed.