Alex Balashov's questions

I have an extremely busy log file (let's call it /var/log/service.log) that is also frequently searched for troubleshooting reasons. Output to it is nearly continuous and 24/7. It probably puts out around 1-2 GB/day, but we need all of it.

Because fgrep of a large log file is impractically slow, there is a need to rotate frequently. I have logrotate set to run in /etc/cron.hourly, with an hourly directive and a size limit of 512M or so.

This works as expected: the file is rotated from /var/log/service.log to /var/log/service.log-20150810 or what have you. The problem is, the renaming is just a cosmetic change on the inode/directory entry, so rsyslogd continues writing to /var/log/service.log-20150810 now and for some time, while the newly created /var/log/service.log sits empty. At some point, rsyslogd does decide to start writing to the new one instead, but I am not clear on its rhyme or reason for doing so.

Anyway, what I need is some way to "kick" rsyslogd to tell it to start writing to a new, pristine /var/log/service.log following the log rotation. Sending it SIGHUP doesn't seem to do the trick. Any ideas that don't involve potentially losing lots of log entries (i.e. restarting rsyslogd) would be appreciated!

(Side note: I gather that the logrotate naming scheme would lead to /var/log/service.log.1 and whatnot, so, I'm a bit puzzled to see /var/log/service.log-20150810 alongside it. Does rsyslogd do its own rotation internally, too? Are there some adverse implications to this?)

Many thanks in advance!

Is it possible to generate a differential dump with mysqldump - between two databases, or, ideally, between a database and a dumped version of that database?

Here's the issue I've got - I have an active/passive HA mirror of MySQL with the actual DB data (the physical MyISAM files, indexes, etc.) residing on a shared DRBD mirror. Last week, the primary node failed and the DRBD master shifted from the primary to the secondary node, and service takeover happened like it was supposed to.

Of course, a bunch of changes have been written to the secondary copy's version of the DRBD mirror, so when the primary comes back up, it takes over the DRBD volume but both sides consider their halves "out of sync" (i.e. StandAlone).

So, now I have a situation where there are two divergent sets of transactions that have taken place on the database:

• That which happened in the time the primary node was down and the data was being written on the secondary;

• That which happened since the primary node came back up and took the services over again; they were never synchronised!

DRBD gives me the ability to revert to either "half" of the mirror (in its current partitioned state) as the "master" revision, but as can be seen, either way causes me to lose data.

Oh, yeah: There was no replication and there were no local transaction logs, so there are no binlogs to replay. Oops. facepalm

There are nightly backups, of course, so I can revert the DB to just about any ~2 AM state from the past year.

I suppose what I'm looking to do is revert to the version of the database that's on the secondary "half" now (i.e. changes that happened while primary was down) and then try to somehow apply the changes in state from that point forward to the present state of the database on the primary's "half" cumulatively.

The problem is, I have no idea how one would go about that without replaying transaction logs.

Insights appreciated, and thanks in advance!

Is there a way to do an apt-get dist-upgrade in Debian that not only automatically answers "yes" to all questions asked, but also uses reasonable defaults as answers to questions that are sophisticated enough to require various interactive dialog boxes to pop up? I'm thinking here of the keymap stuff that shows up when you upgrade libc6, and kernel image choices.

The goal is to be able to remotely initiate a rather large dist-upgrade - even for a machine that is severely behind the times - and not have to babysit it at all, unless something is just horribly, disastrously wrong.

Surely this is possible?

Thanks in advance!

In Apache2, is it possible to bind a VirtualHost to a different IP interface than other virtual hosts, or the server's default Listen address?

The goal is to have a web server that serves some public sites serve some Intranet sites over a VPN interface as well.

I suppose another approach would be to make an .htaccess file that requires passwords from everyone except VPN source addresses, but I would really prefer to be extra careful on that and just not make the sites publicly accessible in the first place.

Thank you very much in advance!