Hi List I am still struggling with the same issues.
On FreeBSD 11.1, I cannot start the mysql server normally. I have to set innodb_force_recovery to a value of 6 to get it started. And then it is of course in read-only mode. As I understand from previous answers, I should use mysqldump on the mediawiki database, start mysql in a clean environment (alternative port, alternative database directory) and then restore the dump from there. Is this the right approach? I am not quite sure how to make server run in the mentioned clean environment since the startup is normally handled by a standard script and a reasonable my.cnf. Output of ps aux | grep mysql: 1. /usr/local/libexec/mysqld --defaults-extra-file=/usr/local/etc/mysql/my.cnf --basedir=/usr/local --datadir=/var/db/mysql 2. /bin/sh /usr/local/bin/mysqld_safe --defaults-extra-file=/usr/local/etc/mysql/my.cnf --basedir=/usr/local --datadir=/var/db/mysql Should I create a modified my.cnf with a different listening port - and not define basedir nor datadir - and the start the server with the same commands? Best regards, Jon Theil Nielsen man. 13. nov. 2017 kl. 19.29 skrev Jon Theil Nielsen <[email protected]>: > Hi Greg, > > Have been away from this topic for some time, but it's still an actual > problem. > > Still in the category of stupid questions (I read the link at least): No > problem to configure the old server as master if the steps are just to put > > server-id = 1 > log_bin = /var/log/mysql/mysql-bin.log > expire_logs_days = 1 > max_binlog_size = 100M > > into my.cnf. > > Are any special content I should throw into the configuration for the > alternative my.cnf? And should the second server be started by mysqld_safe? > Normally in FreeBSD, it is handled by the service script. > > Best regards, > Jon Theil Nielsen > > tor. 2. nov. 2017 kl. 20.01 skrev Greg Rundlett (freephile) < > [email protected]>: > >> Hi Jon, >> >> What version of MySQL are you using (5.7.?) If using the latest MySQL or >> MariaDB server, you'll have better performance and features. At 5.7.x, >> you've already got full-text searching in innodb tables. >> >> As Jan Steinman pointed out, in general, always dump your data using >> mysqldump (as opposed to making backups by directly copying files in the >> data directory). >> >> You should load your database dumps into a clean server environment. That >> means an empty data directory. If you've got sufficient backups (test >> them >> to make sure they are!), then you can rm -rf $my_data_dir/ But it's just >> as easy to setup a different path e.g. /var/lib/data_dir_new and configure >> that when starting a second MySQL instance. >> >> https://www.linux.com/learn/howto-reconfigure-mysql-use-innodbfilepertable-zero-downtime >> is an article that might give you a little perspective on running multiple >> instances of MySQL In short, just like Apache can listen on multiple >> ports >> besides just port 80; and can have multiple websites, each with their own >> document root, so too can MySQL run multiple servers simultaneously, on >> different ports, with different data directories and databases configured >> per server. >> >> From the error messages, it looks like you restored the dump files into >> the >> same MySQL server with pre-existing logs or binlogs. You may need to >> change the configuration of my.cnf to force recovery in that environment >> if >> that's all you've got. See >> https://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html I'm >> guessing that you might need to set it as high as 5 in order to be able to >> start the server and get new dumps. But you might not need this at all if >> you have dumps of all the existing databases and just use those to restore >> them to a _new_ server. You can re-use the same machine, just create a >> different environment for trying the restoration. >> >> ~ Greg >> >> Greg Rundlett >> https://eQuality-Tech.com >> https://freephile.org >> >> On Thu, Nov 2, 2017 at 2:29 PM, Jon Theil Nielsen <[email protected]> >> wrote: >> >> > Hi again, >> > >> > I renovered a database backup and most content seems okay. When I go to >> the >> > last edited page, I get [WfthQ25Pv5U0xFGOqSbrEAAAAJI] 2017-11-02 >> 18:17:40: >> > Fatal undtagelse af typen "MWException". >> > >> > The error log show something like: >> > "[Note] Beginning of list of non-natively partitioned tables >> > 2017-11-02T18:50:03.335153+01:00 0 [ERROR] InnoDB: Page [page id: >> > space=4273, page number=198] log sequence number 26407638763 is in the >> > future! Current sys >> > tem log sequence number 26407537465. >> > 2017-11-02T18:50:03.335166+01:00 0 [ERROR] InnoDB: Your database may be >> > corrupt or you may have copied the InnoDB tablespace but not the InnoDB >> log >> > files. P >> > lease refer to >> > http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html for >> > information about forcing recovery. >> > 2017-11-02T18:50:03.335715+01:00 0 [ERROR] InnoDB: Page [page id: >> > space=4273, page number=200] log sequence number 26407699757 is in the >> > future! Current sys >> > tem log sequence number 26407537465. >> > 2017-11-02T18:50:03.335723+01:00 0 [ERROR] InnoDB: Your database may be >> > corrupt or you may have copied the InnoDB tablespace but not the InnoDB >> log >> > files. P >> > lease refer to >> > http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html for >> > information about forcing recovery. >> > 2017-11-02T18:50:03.335926+01:00 0 [ERROR] InnoDB: Page [page id: >> > space=4273, page number=209] log sequence number 26407637009 is in the >> > future! Current sys >> > tem log sequence number 26407537465. >> > 2017-11-02T18:50:03.335934+01:00 0 [ERROR] InnoDB: Your database may be >> > corrupt or you may have copied the InnoDB tablespace but not the InnoDB >> log >> > files. P >> > lease refer to >> > http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html for >> > information about forcing recovery. >> > 2017-11-02T18:50:03.336872+01:00 0 [ERROR] InnoDB: Page [page id: >> > space=4273, page number=218] log sequence number 26407545138 is in the >> > future! Current sys >> > tem log sequence number 26407537465. >> > 2017-11-02T18:50:03.336880+01:00 0 [ERROR] InnoDB: Your database may be >> > corrupt or you may have copied the InnoDB tablespace but not the InnoDB >> log >> > files. P >> > lease refer to >> > http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html for >> > information about forcing recovery. >> > 2017-11-02T18:50:03.337651+01:00 0 [ERROR] InnoDB: Page [page id: >> > space=4273, page number=224] log sequence number 26407591650 is in the >> > future! Current sys >> > tem log sequence number 26407537465. >> > 2017-11-02T18:50:03.337659+01:00 0 [ERROR] InnoDB: Your database may be >> > corrupt or you may have copied the InnoDB tablespace but not the InnoDB >> log >> > files. P >> > lease refer to >> > http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html for >> > information about forcing recovery. >> > 2017-11-02T18:50:03.339717+01:00 0 [ERROR] InnoDB: Page [page id: >> > space=4273, page number=240] log sequence number 26407701489 is in the >> > future! Current sys >> > tem log sequence number 26407537465. >> > 2017-11-02T18:50:03.339726+01:00 0 [ERROR] InnoDB: Your database may be >> > corrupt or you may have copied the InnoDB tablespace but not the InnoDB >> log >> > files. P >> > lease refer to >> > http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html for >> > information about forcing recovery. >> > 2017-11-02T18:50:03.342125+01:00 0 [ERROR] InnoDB: Page [page id: >> > space=4273, page number=250] log sequence number 26407693838 is in the >> > future! Current sys >> > tem log sequence number 26407537465. >> > 2017-11-02T18:50:03.342134+01:00 0 [ERROR] InnoDB: Your database may be >> > corrupt or you may have copied the InnoDB tablespace but not the InnoDB >> log >> > files. P >> > lease refer to >> > http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html for >> > information about forcing recovery. >> > 2017-11-02T18:50:03.412462+01:00 0 [Note] InnoDB: Buffer pool(s) load >> > completed at 171102 18:50:03 >> > 2017-11-02T18:50:03.468574+01:00 0 [Note] End of list of non-natively >> > partitioned tables >> > 2017-11-02T18:50:23.722273+01:00 3 [ERROR] /usr/local/libexec/mysqld: >> > Table >> > './mediawiki_something_dk/searchindex' is marked as crashed and should >> be >> > repaired >> > 2017-11-02T18:50:23.722478+01:00 3 [Warning] Checking table: >> > './mediawiki_something_dk/searchindex' >> > " >> > Any suggestions about what to do next? >> > >> > Best regards, >> > Jon Theil Nielsen >> > >> > tor. 2. nov. 2017 kl. 12.12 skrev Jon Theil Nielsen <[email protected] >> >: >> > >> > > "He" (me, "the OP") did that following some - maybe bad - advice >> found in >> > > another place. But I haven't used mediawiki for a while – so I do have >> > > backups from 2017-08-31 that should be okay. >> > > So what are your suggestions from here? Just copy (not move) it back >> an >> > > try if i works? Or there might be more clever approaches? >> > > >> > > Best regards, >> > > Jon Theil Nielsen >> > > >> > > tor. 2. nov. 2017 kl. 11.35 skrev Tim Starling < >> [email protected] >> > >: >> > > >> > >> On 02/11/17 03:51, Jon Theil Nielsen wrote: >> > >> > Dear List Users, >> > >> > >> > >> > I have mediawiki 1.29-Release running on FreeBSD-11.1-Release and >> have >> > >> had >> > >> > a crash of my MySQL database. At first, I couldn't start it at all. >> > But >> > >> > after deleting ib_logfile* and ibdata*, it came back alive. In the >> > sense >> > >> > that I can start the server and use many of the databases. But not >> the >> > >> one >> > >> > holding my mediawiki installation. >> > >> > >> > >> > The error log says >> > >> > "[Warning] InnoDB: InnoDB: Cannot open table >> > mediawiki_something_dk/user >> > >> > from the >> > >> > internal data dictionary of InnoDB though the .frm file for the >> table >> > >> > exists.." >> > >> > The debug log is quite full but has the message >> > >> > "Error: 1146 Table 'mediawiki_something_dk.l10n_cache' doesn't >> exist >> > >> > (localhost)" >> > >> > >> > >> > Does anyone know how to solve this? Or maybe have somehere, I can >> look >> > >> for >> > >> > a solution. >> > >> >> > >> I'm not sure what sort of solution you're looking for. You deleted >> the >> > >> InnoDB data file (ibdata*), and now it unsurprisingly says the InnoDB >> > >> data file is gone. That file had your wiki in it, now it's gone. >> > >> >> > >> If you have backups, we can talk about how to recover from them. >> > >> Otherwise, DROP DATABASE mediawiki_something_dk; might possibly wipe >> > >> those .frm files and put the database back into a consistent (empty) >> > >> state. Not sure, I've never heard of anyone deleting ibdata file >> > >> before. If it does work, then you can make a new empty wiki, if that >> > >> is a useful thing for you. >> > >> >> > >> Greg Rundlett wrote: >> > >> > Go ahead and stop Apache, and if you haven't already, make a disk >> copy >> > >> of >> > >> > your mysql data directory for backups. >> > >> >> > >> It's a bit late for that, he's literally deleted his entire wiki. >> > >> >> > >> -- Tim Starling >> > >> >> > >> >> > >> _______________________________________________ >> > >> MediaWiki-l mailing list >> > >> To unsubscribe, go to: >> > >> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l >> > >> >> > > -- >> > > Jon Theil Nielsen >> > > >> > -- >> > Jon Theil Nielsen >> > _______________________________________________ >> > MediaWiki-l mailing list >> > To unsubscribe, go to: >> > https://lists.wikimedia.org/mailman/listinfo/mediawiki-l >> > >> _______________________________________________ >> MediaWiki-l mailing list >> To unsubscribe, go to: >> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l >> > -- > Jon Theil Nielsen > -- Jon Theil Nielsen _______________________________________________ MediaWiki-l mailing list To unsubscribe, go to: https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
