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) <
greg(a)freephile.com>gt;:
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-…
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 <jontheil(a)gmail.com>
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 <jontheil(a)gmail.com
:
> "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 <
tstarling(a)wikimedia.org
>:
>
>> 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