Re: [Maria-discuss] Known limitation with TokuDB in Read Free Replication & parallel replication ?

[jocelyn fournier]

I'll try to extract from the binlog operations applied to only one 
table, and see if I can reproduce easily the issue.


Did you try to run the replication test with the tokudb engine instead 
of innodb ? (just in case it could be easily reproduced with the 
existing tests)



  Jocelyn


Le 15/07/2016 à 17:45, Kristian Nielsen a écrit :

Do you have a test case that can be used to repeat the bug?

  - Kristian.



___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp

[Maria-discuss] maillist break dkim signed mails

[Benny Pedersen]

but when will it stop that practice ?

___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp

Re: [Maria-discuss] Known limitation with TokuDB in Read Free Replication & parallel replication ?

[jocelyn fournier]

Le 15/07/2016 à 17:27, jocelyn fournier a écrit :



Le 15/07/2016 à 17:09, Kristian Nielsen a écrit :

jocelyn fournier  writes:


Thanks for the quick answer! I wonder if it would be possible the
automatically disable the optimistic parallel replication for an
engine if it does not implement it ?
That would probably be good - though it would be better to just 
implement
the necessary API, it's a very small change (basically TokuDB just 
needs to

inform the upper layer of any lock waits that take place inside).

However, looking more at your description, you got a "key not found"
error. Not implementing the thd_report_wait_for() could lead to 
deadlocks,

but it shouldn't cause key not found. In fact, in optimistic mode, all
errors are treated as "deadlock" errors, the query is rolled back, and
run again, this time not in parallel.

So I'm wondering if there is something else going on. If 
transactions T1 and
T2 run in parallel, it's possible that they have a row conflict. But 
if T2
deleted a row expected by T1, I would expect T1 to wait on a row 
lock held
by T2, not get a duplicate key error. And if T1 has not yet inserted 
a row

expected by T2, then T2 would be rolled back and retried after T1 has
committed. The first can cause deadlock, but neither case seems to 
cause

duplicate error.

Maybe TokuDB is doing something special with locks around 
replication, or
something else goes wrong. I guess TokuDB just hasn't been tested 
much with

parallel replication.

Does it work ok when running in conservative parallel mode?

So far conservative parallel mode seems to work properly as well.
My first thought was that this issue was cause by the Read Free 
Replication not locking rows in the expected way, although it's 
advertised to be 100% compatible with parallel replication.
I'll try the optimistic mode without the Read Free Replication to 
check if it could be related.



Well same issue without RFR :

Could not execute Delete_rows_v1 event on table sc_2.sc_product_genre; 
Can't find record in 'sc_product_genre', Error_code: 1032; handler 
error HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin.008420, 
end_log_pos 77519956


(and it didn't succeed in recovering this one, I had to skip it).



Actually it has definitly corrupted the state of the slave, I have to 
rebuild the replication from a backup.


  Jocelyn

___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp

Re: [Maria-discuss] Known limitation with TokuDB in Read Free Replication & parallel replication ?

[Kristian Nielsen]

Do you have a test case that can be used to repeat the bug?

 - Kristian.

___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp

Re: [Maria-discuss] Known limitation with TokuDB in Read Free Replication & parallel replication ?

[jocelyn fournier]

Le 15/07/2016 à 17:27, jocelyn fournier a écrit :



Le 15/07/2016 à 17:09, Kristian Nielsen a écrit :

jocelyn fournier  writes:


Thanks for the quick answer! I wonder if it would be possible the
automatically disable the optimistic parallel replication for an
engine if it does not implement it ?
That would probably be good - though it would be better to just 
implement
the necessary API, it's a very small change (basically TokuDB just 
needs to

inform the upper layer of any lock waits that take place inside).

However, looking more at your description, you got a "key not found"
error. Not implementing the thd_report_wait_for() could lead to 
deadlocks,

but it shouldn't cause key not found. In fact, in optimistic mode, all
errors are treated as "deadlock" errors, the query is rolled back, and
run again, this time not in parallel.

So I'm wondering if there is something else going on. If transactions 
T1 and
T2 run in parallel, it's possible that they have a row conflict. But 
if T2
deleted a row expected by T1, I would expect T1 to wait on a row lock 
held
by T2, not get a duplicate key error. And if T1 has not yet inserted 
a row

expected by T2, then T2 would be rolled back and retried after T1 has
committed. The first can cause deadlock, but neither case seems to cause
duplicate error.

Maybe TokuDB is doing something special with locks around 
replication, or
something else goes wrong. I guess TokuDB just hasn't been tested 
much with

parallel replication.

Does it work ok when running in conservative parallel mode?

So far conservative parallel mode seems to work properly as well.
My first thought was that this issue was cause by the Read Free 
Replication not locking rows in the expected way, although it's 
advertised to be 100% compatible with parallel replication.
I'll try the optimistic mode without the Read Free Replication to 
check if it could be related.



Well same issue without RFR :

Could not execute Delete_rows_v1 event on table sc_2.sc_product_genre; 
Can't find record in 'sc_product_genre', Error_code: 1032; handler error 
HA_ERR_KEY_NOT_FOUND; the event's master log mysql-bin.008420, 
end_log_pos 77519956


(and it didn't succeed in recovering this one, I had to skip it).

  Jocelyn


___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp

Re: [Maria-discuss] Known limitation with TokuDB in Read Free Replication & parallel replication ?

[Kristian Nielsen]

jocelyn fournier  writes:

> Thanks for the quick answer! I wonder if it would be possible the
> automatically disable the optimistic parallel replication for an
> engine if it does not implement it ?

That would probably be good - though it would be better to just implement
the necessary API, it's a very small change (basically TokuDB just needs to
inform the upper layer of any lock waits that take place inside).

However, looking more at your description, you got a "key not found"
error. Not implementing the thd_report_wait_for() could lead to deadlocks,
but it shouldn't cause key not found. In fact, in optimistic mode, all
errors are treated as "deadlock" errors, the query is rolled back, and
run again, this time not in parallel.

So I'm wondering if there is something else going on. If transactions T1 and
T2 run in parallel, it's possible that they have a row conflict. But if T2
deleted a row expected by T1, I would expect T1 to wait on a row lock held
by T2, not get a duplicate key error. And if T1 has not yet inserted a row
expected by T2, then T2 would be rolled back and retried after T1 has
committed. The first can cause deadlock, but neither case seems to cause
duplicate error.

Maybe TokuDB is doing something special with locks around replication, or
something else goes wrong. I guess TokuDB just hasn't been tested much with
parallel replication.

Does it work ok when running in conservative parallel mode?

 - Kristian.

___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp

Re: [Maria-discuss] after set replicate_wild_do_table, binlog file could not update ?

[Will Fong]

Hi,

On Fri, Jul 15, 2016 at 9:13 PM, Ljr Yang  wrote:
> IF add replicate_wild_do_table='test01.%,mysql.%' in slave's my.cnf file and
> restart salve, replication normal, relay_log file could update, but log_bin
> file could not update.

You cannot specify more than one pattern here. You need to use this
option more than one time.

https://mariadb.com/kb/en/mariadb/replication-and-binary-log-server-system-variables/#replicate_wild_do_table

"The directive does not accept a comma-delimited list, and needs to be
used multiple times to specify multiple wildcard patterns (on both the
commandline and in configuration files)."

Hope this helps.

-will


-- 
Will Fong, Senior Support Engineer
MariaDB Corporation

___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp

Re: [Maria-discuss] Known limitation with TokuDB in Read Free Replication & parallel replication ?

[Kristian Nielsen]

jocelyn fournier  writes:

> After upgrading from TokuDB Enterprise with MariaDB 5.5 to MariaDB
> 10.1.14, I tried to enable the parallel replication
> (parallel_mode=optimistic, slave_parallel_threads=4) on a GTID enabled

> Is this a known limitation with TokuDB ?

Yes. TokuDB does not (to my knowledge) implement the thd_report_wait_for()
API, which is what makes optimistic parallel replication work.

 - Kristian.

___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp

Re: [Maria-discuss] mariadb-connect-engine-10.1 : Depends: unixODBC but it is not installable

[Umarzuki Mochlis]

Thanks glad to hear that.

2016-07-15 17:55 GMT+08:00 Sergei Golubchik :
> Hi, Umarzuki!
>
> On Jul 13, Umarzuki Mochlis wrote:
>> 2 of 3 mariadb servers 10.1, ubuntu 16.04 unable to install
>> mariadb-connect-engine-10.1 with error
>>
>> The following packages have unmet dependencies:
>>  mariadb-connect-engine-10.1 : Depends: unixODBC but it is not installable
>> E: Unable to correct problems, you have held broken packages.
>>
>> I fould bugreport at https://jira.mariadb.org/browse/MDEV-10032
>>
>> but it seems stalled?
>
> It's closed, the jira page above says that it was fixed in 10.1.15.
>
> But we pulled that release off, it's not in repos.
>
> You'll get a fix for this bug in 10.1.16, which should be released early
> next week.
>
> Regards,
> Sergei
> Chief Architect MariaDB
> and secur...@mariadb.org

___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp

Re: [Maria-discuss] mariadb-connect-engine-10.1 : Depends: unixODBC but it is not installable

[Sergei Golubchik]

Hi, Umarzuki!

On Jul 13, Umarzuki Mochlis wrote:
> 2 of 3 mariadb servers 10.1, ubuntu 16.04 unable to install
> mariadb-connect-engine-10.1 with error
> 
> The following packages have unmet dependencies:
>  mariadb-connect-engine-10.1 : Depends: unixODBC but it is not installable
> E: Unable to correct problems, you have held broken packages.
> 
> I fould bugreport at https://jira.mariadb.org/browse/MDEV-10032
> 
> but it seems stalled?

It's closed, the jira page above says that it was fixed in 10.1.15.

But we pulled that release off, it's not in repos.

You'll get a fix for this bug in 10.1.16, which should be released early
next week.

Regards,
Sergei
Chief Architect MariaDB
and secur...@mariadb.org

___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp

Re: [Maria-discuss] Key lengths for file_key_management plugin

[Sergei Golubchik]

Hi, Honza!

On Jul 14, Honza Horak wrote:
> I've asked directly in the documentation page, but maybe someone will 
> know answer here:
> https://mariadb.com/kb/en/mariadb/data-at-rest-encryption/#comment_2346
> 
> In that article it is said that 128, 192 or 256-bit keys are supported, 
> but later AES_CTR and AES_CBC modes talk only about 128bit keys. What 
> piece of information am I missing?

The article says "the plugin will use AES with the 128-bit keys in
the CTR mode for encrypting tablespace pages".

Because tablespace pages are always encrypted with a 128-bit tablespace
key. Which is different for every tablespace and it is generated from
the user-specified key, which might be 128-, 192-, or 256-bit.

Temporary files and binary logs are encrypted directly with the
user-specified key of a user-specified length.

Regards,
Sergei
Chief Architect MariaDB
and secur...@mariadb.org

___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp

[Maria-discuss] New Question: Galera Cluster In MariaDB Tarball 10.1.14

[AskMonty KB]

Hello,

A new question has been asked in "MariaDB FAQ" by palash.harchandani93_43595. 
Please answer it at 
http://mariadb.com/kb/en/galera-cluster-in-mariadb-tarball-10114/ as the person 
asking the question may not be subscribed to the mailing list.


I am not able to configure mariadb galera cluster using 
mariadb-enterprise-10.1.14-linux-x86_64.tar.gz file as there are no galera 
libraries. is it possible to configure galera cluster using this tarball 
package. please provide a link from where to download galera libraries for 
tarball packages.


To view or answer this question please visit: 
http://mariadb.com/kb/en/galera-cluster-in-mariadb-tarball-10114/

___
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help   : https://help.launchpad.net/ListHelp