Suppose you have a master-master replication setup, and you know one of the tables has the wrong data. How do you re-sync it with the other server? Warning: don’t just use any tool for this job! You may destroy your good copy of the data. If your table is large, you’ll probably want to use a tool that can smartly find the differences in a very large dataset, and fix only the rows that need to be fixed.

i completed all the paperwork to accept my new position at sun today. now i just need to drop it off at a ups dropbox or have ups pick it up. at least they didn’t ask me to fax anything.

for a hardware company trying to become a software company, you would think the process of “onboarding” would not involve writing your address on a half-dozen different forms.

i will be a “member of the technical staff 4 - software.”

yeah, they say that they are working on updating the titles and such for everyone.

$11.4 billion is wasted each year on software patent litigation, according to the End Software Patents coalition. How did it get to the $11.4 billion figure?

• Dan Ravicher of the Public Patent Foundation estimates that 55 software patent suits are filed every week.
• The American Intellectual Property Lawyer's Association states that a single mid-sized patent suit costs $4 million to litigate.

That's a lot of billable hours. However, it's perhaps not surprising given that patent swine like Global Holdings illegitimately attempt to extort patent royalties from unsuspecting enterprises:

...

Forge 2.0 was announced yesterday, and Jay and I were bracing ourselves for an avalanche of bugs, which did not come.
When Bug#34916 (Login not working on new forge site) was reported, I thought nothing of it. It was simply the wrong environment. The reporter could not log in, because he did not have an account.

I explained the problem, and felt good about it.
Sometimes I experienced reporting a bug and being told that it was intended behavior, not a bug, read the manual, thanks for writing, and that was it. So dry and clueless. Not inspiring for a further analysis.
So I took some minutes to explain what had happened, before closing the bug with the fatal words.
And the reporter, …

So, one of master server’s disk filled up with replication logs last night. We had a permission issue due to our data center move. An oversight on my part. Anyhow, I got to the server and purged the old logs and the master server started responding with no problems. However, the slaves did not. Both slaves connected to the master would not respond to a slave stop. Nor would they respond to a mysqladmin shutdown. I had to kill -9 the daemons to get them to stop. When I restarted the daemon and started the slave, all was fine.

I am hoping someone knows what is going on or can tell me what to send in a bug report. I don’t want to just put that in a bug report. It is kind of lame and useless.

Update: This may be my problem. Bug #31024.  I certainly did not give the slave a long time to stop.

…

MySQL master servers won’t remove their logs automatically when slaves are done with them. You can set expire_logs_days to remove them after a certain number of days. But, you are not assured that a slave is done with the logs. So, we wrote a script to connect to slaves and then purge logs on the master servers. It works for us. Your mileage may vary. BSD style license. Enjoy.

flush_mysql_master.php.gz

…

I spent some time going through the source the other day in order to try to understand the difference between these SHOW STATUS variables in 5.x:

Innodb_buffer_pool_read_requests Innodb_buffer_pool_reads Innodb_pages_read
Here's what I discovered that I'm not sure is 100% right, but I suspect is at least on the right track:
Innodb_buffer_pool_read_requests:  requests to get something from the buffer pool.  This isn't really that great of a mystery.  I suspect these are 'direct' read requests, meaning those caused directly from a query of some kind.  

read more

I spent some time going through the source the other day in order to try to understand the difference between these SHOW STATUS variables in 5.x:

Innodb_buffer_pool_read_requests Innodb_buffer_pool_reads Innodb_pages_read
Here's what I discovered that I'm not sure is 100% right, but I suspect is at least on the right track:
Innodb_buffer_pool_read_requests:  requests to get something from the buffer pool.  This isn't really that great of a mystery.  I suspect these are 'direct' read requests, meaning those caused directly from a query of some kind.  

read more

A new version of myq_gadgets has been released and you can download it here.

Changelog since the last released version here:

Version 0.0.9 -
    - Documented new reports in README
    - Updated 'thds' column in the 'cttf' report to read 'crtd' instead.
Version 0.0.8 -
    - Added a bunch more innodb reports, looking for the good stuff.
Version 0.0.7 -
    - Added an 'innodb' mode to myq_status to support 5.0+ STATUS variables.
      'myq_innodb_status' continues to handle SHOW INNODB STATUS output,
      mostly for 4.1 and earlier.
    - Beefed up the format_memory function to use recursion to determine the
      appropriate output multiplier (tera, giga, mega, kilo, etc.)

A new version of myq_gadgets has been released and you can download it here.

Changelog since the last released version here:

Version 0.0.9 -
    - Documented new reports in README
    - Updated 'thds' column in the 'cttf' report to read 'crtd' instead.
Version 0.0.8 -
    - Added a bunch more innodb reports, looking for the good stuff.
Version 0.0.7 -
    - Added an 'innodb' mode to myq_status to support 5.0+ STATUS variables.
      'myq_innodb_status' continues to handle SHOW INNODB STATUS output,
      mostly for 4.1 and earlier.
    - Beefed up the format_memory function to use recursion to determine the
      appropriate output multiplier (tera, giga, mega, kilo, etc.)