headers
Mats Kindahl | 1 Aug 2012 14:29
Picon
Favicon

Re: question about the innodb recovery log

On 07/31/2012 05:28 PM, Rich Prohaska wrote:
> Hello,
> The innodb-safe-binlog variable no longer exists, but the binlog
> position is still stuffed into the innodb recovery log.  Using recent
> MySQL versions, does this assist the DBA when running point in time
> recovery?

Hello Rich,

The position is printed on recovery and mainly to assist in provisioning
new slaves. The position can be used to know where to start replication
from, once the backup have been restored on a new slave. It can, as you
noted, also be used for point in time recovery.

To my knowledge, the position is not used anywhere else. In particular,
it is not used when recovering the server from a crash.

Just my few cents,
Mats Kindahl

> Thanks
>
> On Fri, Jul 27, 2012 at 3:27 PM, Hartmut Holzgraefe
> <hartmut.holzgraefe <at> gmail.com> wrote:
>>> Why does InnoDB log the binlog position in its recovery log when a
>>> transaction commits?
>> as it needs to find out whether InnoDB state and binlog position are in
>> sync during recovery?
>>
>> See
(Continue reading)

Permalink | Reply | 0 comments |
headers
Rich Prohaska | 2 Aug 2012 22:17
Favicon

A change to the partition engine error recovery in mysql 5.6.6

Hello,
I made the following change to the 5.6.6-labs-june-2012 codebase to
get the partition engine error recovery to work with TokuDB.  The code
is trying to drop a successfully added key.  It would be nice to
supply the key info for the table with the new key in it, which is
what the change does.

Thanks
Rich Prohaska

--- sql/ha_partition.cc	(revision 46437)
+++ sql/ha_partition.cc	(working copy)
 <at>  <at>  -7328,6 +7328,8  <at>  <at> 
       drop_info.handler_flags|= Alter_inplace_info::DROP_UNIQUE_INDEX;
     if (ha_alter_info->handler_flags & Alter_inplace_info::ADD_PK_INDEX)
       drop_info.handler_flags|= Alter_inplace_info::DROP_PK_INDEX;
+    drop_info.key_info_buffer= ha_alter_info->key_info_buffer;
+    drop_info.key_count= ha_alter_info->key_count;
     drop_info.index_drop_count= ha_alter_info->index_add_count;

--

-- 
MySQL Internals Mailing List
For list archives: http://lists.mysql.com/internals
To unsubscribe:    http://lists.mysql.com/internals
Permalink | Reply | 0 comments |
headers
Rich Prohaska | 3 Aug 2012 22:59
Picon

Re: question about the innodb recovery log

Hello,
This blog (http://http://kristiannielsen.livejournal.com/12553.html,
one of a sequence of blogs on the topic of binlog group commit and
fsync performance) provides a very nice answer to my question.

On Fri, Jul 27, 2012 at 2:27 PM, Rich Prohaska <prohaska <at> tokutek.com> wrote:
> Hello,
> Why does InnoDB log the binlog position in its recovery log when a
> transaction commits?
> Thanks
> Rich Prohaska
>
> --
> MySQL Internals Mailing List
> For list archives: http://lists.mysql.com/internals
> To unsubscribe:    http://lists.mysql.com/internals
>

--

-- 
MySQL Internals Mailing List
For list archives: http://lists.mysql.com/internals
To unsubscribe:    http://lists.mysql.com/internals
Permalink | Reply | 0 comments |
headers
Sergei Golubchik | 9 Aug 2012 13:16
Favicon

test cases?

Hi,

Looking at the changes between mysql-5.5.25 and mysql-5.5.27,
I noticed that while it contains quite a few bug fixes, they all come
without test cases.

What would that be - a change in policy? Careless developers?

On the other hand, 5.5.27 contains a change to mysql-test-run to look
for test cases in the new directory, named "internal".

May be all new tests are there? That is, tests are no longer
open-source?

Whatever the reason is - everyone, who modifies MySQL (all linux
distributions, facebook, twitter, taobao, and many others) have
just lost the ability to test their extensions.

Could anyone from Oracle shed some light on this?
Where did the new test cases go?

Regards,
Sergei

--

-- 
MySQL Internals Mailing List
For list archives: http://lists.mysql.com/internals
To unsubscribe:    http://lists.mysql.com/internals
(Continue reading)

Permalink | Reply | 3 comments |
headers
MARK CALLAGHAN | 9 Aug 2012 13:39
Picon

Re: test cases?

If true this is also an issue for some users who don't modify MySQL
source. They still want to confirm that bugs are fixed in new
releases. Others want to confirm that binaries they compiled don't
have any obvious bugs.

On Thu, Aug 9, 2012 at 4:16 AM, Sergei Golubchik <serg <at> askmonty.org> wrote:
> Hi,
>
> Looking at the changes between mysql-5.5.25 and mysql-5.5.27,
> I noticed that while it contains quite a few bug fixes, they all come
> without test cases.
>
> What would that be - a change in policy? Careless developers?
>
> On the other hand, 5.5.27 contains a change to mysql-test-run to look
> for test cases in the new directory, named "internal".
>
> May be all new tests are there? That is, tests are no longer
> open-source?
>
> Whatever the reason is - everyone, who modifies MySQL (all linux
> distributions, facebook, twitter, taobao, and many others) have
> just lost the ability to test their extensions.
>
> Could anyone from Oracle shed some light on this?
> Where did the new test cases go?
>
> Regards,
> Sergei
>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Davi Arnaut | 9 Aug 2012 21:34
Favicon
Gravatar

Re: test cases?

On top of the aforementioned, there was a change in policy that a
change log for a particular release will now only be published when
the release becomes available for download. Also, the commits going to
the commits mailing list are now quite infrequent and mostly
irrelevant.

It seems that the few things that were developed in a somewhat open
manner no longer exist. It would be nice to know what is going on. It
might be seem as a direct attack on whoever develops on top of the
upstream MySQL.

On Thu, Aug 9, 2012 at 4:39 AM, MARK CALLAGHAN <mdcallag <at> gmail.com> wrote:
> If true this is also an issue for some users who don't modify MySQL
> source. They still want to confirm that bugs are fixed in new
> releases. Others want to confirm that binaries they compiled don't
> have any obvious bugs.
>
> On Thu, Aug 9, 2012 at 4:16 AM, Sergei Golubchik <serg <at> askmonty.org> wrote:
>> Hi,
>>
>> Looking at the changes between mysql-5.5.25 and mysql-5.5.27,
>> I noticed that while it contains quite a few bug fixes, they all come
>> without test cases.
>>
>> What would that be - a change in policy? Careless developers?
>>
>> On the other hand, 5.5.27 contains a change to mysql-test-run to look
>> for test cases in the new directory, named "internal".
>>
>> May be all new tests are there? That is, tests are no longer
(Continue reading)

Permalink | Reply | 1 comment |
headers
MARK CALLAGHAN | 11 Aug 2012 14:09
Picon

Re: test cases?

Davi,

What you describe is a delay in sharing. This thread started with a
question about content (tests for bug fixes) that wasn't shared. I
think those are separate discussions.

This is a great place for the community team to respond.

On Thu, Aug 9, 2012 at 12:34 PM, Davi Arnaut <davi <at> twitter.com> wrote:
> On top of the aforementioned, there was a change in policy that a
> change log for a particular release will now only be published when
> the release becomes available for download. Also, the commits going to
> the commits mailing list are now quite infrequent and mostly
> irrelevant.
>
> It seems that the few things that were developed in a somewhat open
> manner no longer exist. It would be nice to know what is going on. It
> might be seem as a direct attack on whoever develops on top of the
> upstream MySQL.
>
> On Thu, Aug 9, 2012 at 4:39 AM, MARK CALLAGHAN <mdcallag <at> gmail.com> wrote:
>> If true this is also an issue for some users who don't modify MySQL
>> source. They still want to confirm that bugs are fixed in new
>> releases. Others want to confirm that binaries they compiled don't
>> have any obvious bugs.
>>
>> On Thu, Aug 9, 2012 at 4:16 AM, Sergei Golubchik <serg <at> askmonty.org> wrote:
>>> Hi,
>>>
>>> Looking at the changes between mysql-5.5.25 and mysql-5.5.27,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Stewart Smith | 13 Aug 2012 02:46
Gravatar

BZR for 5.1.65?

Seems missing from launchpad, with 5.1 branch last being updated in May.

Oversight? Something broken (again)?
--

-- 
Stewart Smith
Permalink | Reply | 1 comment |
headers
Stewart Smith | 13 Aug 2012 02:50
Gravatar

BZR for 5.6.6?

The trunk branch on launchpad was last updated in May, while 5.6.6 seems
to have been released on 2012-08-07 according to the manual.

Oversight? Very broken automated system?
--

-- 
Stewart Smith
Permalink | Reply | 1 comment |
headers
Stewart Smith | 17 Aug 2012 04:03
Gravatar

BZR trees for current MySQL releases

Hi all,

Like many of you, I'm disappointed that the bzr trees for MySQL are out
of sync with the tarball source and binary releases from Oracle.

Since Oracle has been silent on this, and this is a recurring problem,
I've decided to attempt to help the situation.

I've created the following bzr trees:
lp:percona-server/upstream-5.0
lp:percona-server/upstream-5.1
lp:percona-server/upstream-5.5
lp:percona-server/upstream-5.6

These are going to be exact mirrors of the lp:mysql-server trees, except
where the lp:mysql-server trees lag behind or differ in some
indeterminate way from what has been released as Oracle MySQL - in which
case we'll import the latest released source tarball.

These trees have *NOTHING AT ALL* from Percona Server, they are simply
straight MySQL, as you would download from Oracle or (at least
previously) from the bzr trees hosted on launchpad.

For example, right now, the 5.1 tree differs as MySQL 5.1.65 has been
released but the last tagged release in the lp:mysql-server/5.1 tree is
MySQL 5.1.63.

For cases such as this, I have imported the MySQL source tarball into
the appropriate lp:percona-server/upstream-X tree and will reconcile it
with the Oracle lp:mysql-server/X tree if/when that becomes available.
(Continue reading)

Permalink | Reply | 1 comment |

Gmane