September 2016 - discuss - lists.mariadb.org

[Maria-discuss] R: handling of mixed case roles
by Federico Razzoli 05 Sep '16

05 Sep '16

Users are case-sensitive, so I expect the same from roles. If something doesn't work with mixed-case roles, it is probably a bug. Federico -------------------------------------------- Lun 5/9/16, Robin Peiremans <robin.peiremans(a)kbc.be> ha scritto: Oggetto: [Maria-discuss] handling of mixed case roles A: "maria-discuss(a)lists.launchpad.net" <maria-discuss(a)lists.launchpad.net> Data: Lunedì 5 settembre 2016, 10:27 Hi I've created a role with both upper and lowercase name, resulting in some weird behavior (output and test case below). The first thing I noticed is that you can create roles with the same name but different case (test_role and test_ROLE in below example), but you can't grant both to the same user as that results in an error 1961 when granting the second role. Imo this indicates that not all the roles code is case-sensitive. The second weird thing is that when you get the error 1961 in above scenario, the first role (that was granted successfully) is gone from the show grants output. It is not revoked (the user can still use it), it just isn't shown anymore until I flush privileges. Can this be considered a bug, or am I missing something here? MariaDB version: 10.1.13-MariaDB OS: Red Hat 7.2 Kind regards Robin Output and test case: MariaDB [mysql]> create role test_ROLE; Query OK, 0 rows affected (0.00 sec) MariaDB [mysql]> create role test_role; Query OK, 0 rows affected (0.00 sec) MariaDB [mysql]> grant select on mysql.* to test_role; Query OK, 0 rows affected (0.00 sec) MariaDB [mysql]> select user, host from user where is_role='y' and user like 'test%'; +-----------+------+ | user | host | +-----------+------+ | test_ROLE | | | test_role | | +-----------+------+ 2 rows in set (0.00 sec) MariaDB [mysql]> grant test_role to testuser; Query OK, 0 rows affected (0.00 sec) MariaDB [mysql]> show grants for testuser; +------------------------------------------------------------------------+ | Grants for testuser@% | +------------------------------------------------------------------------+ | GRANT test_role TO 'testuser'@'%' | | GRANT USAGE ON *.* TO 'testuser'@'%' IDENTIFIED VIA pam USING 'mariadb' | +------------------------------------------------------------------------+ 2 rows in set (0.00 sec) MariaDB [mysql]> grant test_ROLE to testuser; ERROR 1961 (HY000): Cannot grant role 'test_ROLE' to: 'testuser'. MariaDB [mysql]> show grants for testuser; +------------------------------------------------------------------------+ | Grants for testuser@% | +------------------------------------------------------------------------+ | GRANT USAGE ON *.* TO 'testuser'@'%' IDENTIFIED VIA pam USING 'mariadb' | +------------------------------------------------------------------------+ 1 row in set (0.00 sec) MariaDB [mysql]> select * from roles_mapping where user='testuser'; +-----------+---------+-----------+--------------+ | Host | User | Role | Admin_option | +-----------+---------+-----------+--------------+ | % | testuser | test_role | N | +-----------+---------+-----------+--------------+ 3 rows in set (0.00 sec) MariaDB [mysql]> flush privileges; Query OK, 0 rows affected (0.00 sec) MariaDB [mysql]> show grants for testuser; +------------------------------------------------------------------------+ | Grants for testuser@% | +------------------------------------------------------------------------+ | GRANT test_role TO 'testuser'@'%' | | GRANT USAGE ON *.* TO 'testuser'@'%' IDENTIFIED VIA pam USING 'mariadb' | +------------------------------------------------------------------------+ 2 rows in set (0.00 sec) Disclaimer -----Segue allegato----- _______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss(a)lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp

1 0

[Maria-discuss] mysqld syslog flood Bad file descriptor
by Raffael Sahli 05 Sep '16

05 Sep '16

Hi Over the weekend I had a problem with one mysqld instance. This single instance flooded our entire syslog infrastructure with ~190mio log entries within 6 hours. The messages was: "140289656219584 [ERROR] Error in accept: Bad file descriptor" mysqld: /usr/sbin/mysqld Ver 10.1.16-MariaDB-1~trusty for debian-linux-gnu on x86_64 (mariadb.org binary distribution) I will configure rsyslog to throttle such entries, but anyways, is this a known problem? Cheers -- Raffael Sahli public(a)raffaelsahli.com

1 0

[Maria-discuss] 回复：Re:__转发：failed_to_connect_mariadb_at_addition_node_in_MariaDB_galera_cluster
by 西门吹牛 03 Sep '16

03 Sep '16

Hi, Thanks for the reponse. No, I started mysqld on the second node via comamd "mysqld --defaults-extra-file=mdb.my.cnf --debug". The problem is permanent. No abnormal output seen from the console. I feel mariadb may stuck somewher. from the trace log(attached mdb.mysqld.trace). it looks stuck at wsrep_replication_process. It may wait for some message from primary node. but I have no ieda what it waits for. -------------------------------- ----- 原始邮件 ----- 发件人：Nirbhay Choubey <nirbhay(a)mariadb.com> 收件人：zh1029(a)sina.com 抄送人：maria-discuss <maria-discuss(a)lists.launchpad.net>, "yan-jack.chen" <yan-jack.chen(a)nokia.com> 主题：Re:_[Maria-discuss]_转发：failed_to_connect_mariadb_at_addition_node_in_MariaDB_galera_cluster 日期：2016年09月02日 23点26分 Hi, On Thu, Sep 1, 2016 at 11:08 PM, 西门吹牛 <zh1029(a)sina.com> wrote: Hi, I deployed two MariaDB galera version in two nodes to build cluster. But I can’t connect MariaDB in second node as seems the port is not created by MariaDB because looks like it is stuck somehow. Version: mysqld 10.1.17-MariaDB-debug VS galera-3-25.3.17 I started MariaDB in first node. Seems fine. Port 3307 was created and I can login Mariadb by mysql. You shouldn't use --wsrep-new-cluster to start the 2nd node (in case you are).Regarding the hang:Does it happen all the time? Repeatable?Is that all you see in the error log? Nothing after the partial last line?Will it be possible to attach mysqld to some debugger to check where exactly does it hang? Best,Nirbhay [root@MMN-0(RCP-69) /root/test] # /home/_rcpadmin/bin/mariadb/bin/mysqld --defaults-extra-file=./mmn.my.cnf --wsrep-new-cluster --debug 2016-09-01 16:41:37 140716544316288 [Note] /home/_rcpadmin/bin/mariadb/bin/mysqld (mysqld 10.1.17-MariaDB-debug) starting as process 15248 ... 2016-09-01 16:41:38 140716544316288 [Note] WSREP: Setting wsrep_ready to 0 2016-09-01 16:41:38 140716544316288 [Note] WSREP: Read nil XID from storage engines, skipping position init 2016-09-01 16:41:38 140716544316288 [Note] WSREP: wsrep_load(): loading provider library '/usr/lib64/libgalera_smm.so' 2016-09-01 16:41:38 140716544316288 [Note] WSREP: wsrep_load(): Galera 3.17(r0) by Codership Oy <info(a)codership.com> loaded successfully. 2016-09-01 16:41:38 140716544316288 [Note] WSREP: CRC-32C: using hardware acceleration. 2016-09-01 16:41:38 140716544316288 [Note] WSREP: Found saved state: 900987cc-7003-11e6-b25f-de0a52317f1d:0 2016-09-01 16:41:38 140716544316288 [Note] WSREP: Passing config to GCS: base_dir = /mariadb/; base_host = MMN-0; base_port = 4567; cert.log_conflicts = no; debug = no; evs.auto_evict = 0; evs.delay_margin = PT1S; evs.delayed_keep_period = PT30S; evs.inactive_check_period = PT0.5S; evs.inactive_timeout = PT15S; evs.join_retrans_period = PT1S; evs.max_install_timeouts = 3; evs.send_window = 4; evs.stats_report_period = PT1M; evs.suspect_timeout = PT5S; evs.user_send_window = 2; evs.view_forget_timeout = PT24H; gcache.dir = /mariadb/; gcache.keep_pages_size = 0; gcache.mem_size = 0; gcache.name = /mariadb//galera.cache; gcache.page_size = 300M; gcache.size = 300M; gcomm.thread_prio = ; gcs.fc_debug = 0; gcs.fc_factor = 1.0; gcs.fc_limit = 16; gcs.fc_master_slave = no; gcs.max_packet_size = 64500; gcs.max_throttle = 0.25; gcs.recv_q_hard_limit = 9223372036854775807; gcs.recv_q_soft_limit = 0.25; gcs.sync_donor = no; gmcast.segment = 0; gmcast.version = 0; pc.announce_timeout = PT3S; pc.checksum = false; pc.ignore_quorum = false; pc.ignore_sb = false; pc 2016-09-01 16:41:38 140716029634304 [Note] WSREP: Service thread queue flushed. 2016-09-01 16:41:38 140716544316288 [Note] WSREP: Assign initial position for certification: 0, protocol version: -1 2016-09-01 16:41:38 140716544316288 [Note] WSREP: wsrep_sst_grab() 2016-09-01 16:41:38 140716544316288 [Note] WSREP: Start replication 2016-09-01 16:41:38 140716544316288 [Note] WSREP: 'wsrep-new-cluster' option used, bootstrapping the cluster 2016-09-01 16:41:38 140716544316288 [Note] WSREP: Setting initial position to 900987cc-7003-11e6-b25f-de0a52317f1d:0 2016-09-01 16:41:38 140716544316288 [Note] WSREP: protonet asio version 0 2016-09-01 16:41:38 140716544316288 [Note] WSREP: Using CRC-32C for message checksums. 2016-09-01 16:41:38 140716544316288 [Note] WSREP: backend: asio 2016-09-01 16:41:38 140716544316288 [Note] WSREP: gcomm thread scheduling priority set to other:0 2016-09-01 16:41:38 140716544316288 [Warning] WSREP: access file(/mariadb//gvwstate.dat) failed(No such file or directory) 2016-09-01 16:41:38 140716544316288 [Note] WSREP: restore pc from disk failed 2016-09-01 16:41:38 140716544316288 [Note] WSREP: GMCast version 0 2016-09-01 16:41:38 140716544316288 [Note] WSREP: (e5a32d3c, 'tcp://0.0.0.0:4567') listening at tcp://0.0.0.0:4567 2016-09-01 16:41:38 140716544316288 [Note] WSREP: (e5a32d3c, 'tcp://0.0.0.0:4567') multicast: , ttl: 1 2016-09-01 16:41:38 140716544316288 [Note] WSREP: EVS version 0 2016-09-01 16:41:38 140716544316288 [Note] WSREP: gcomm: bootstrapping new group 'example_cluster' 2016-09-01 16:41:38 140716544316288 [Note] WSREP: start_prim is enabled, turn off pc_recovery 2016-09-01 16:41:38 140716544316288 [Note] WSREP: Node e5a32d3c state prim 2016-09-01 16:41:38 140716544316288 [Note] WSREP: view(view_id(PRIM,e5a32d3c,1) memb { e5a32d3c,0 } joined { } left { } partitioned { }) 2016-09-01 16:41:38 140716544316288 [Note] WSREP: save pc into disk 2016-09-01 16:41:38 140716544316288 [Note] WSREP: discarding pending addr without UUID: tcp://169.254.0.4:4567 2016-09-01 16:41:38 140716544316288 [Note] WSREP: discarding pending addr proto entry 0x5652b0352ef0 2016-09-01 16:41:38 140716544316288 [Note] WSREP: discarding pending addr without UUID: tcp://169.254.0.5:4567 2016-09-01 16:41:38 140716544316288 [Note] WSREP: discarding pending addr proto entry 0x5652b035b720 2016-09-01 16:41:38 140716544316288 [Note] WSREP: discarding pending addr without UUID: tcp://169.254.0.6:4567 2016-09-01 16:41:38 140716544316288 [Note] WSREP: discarding pending addr proto entry 0x5652b0363ea0 2016-09-01 16:41:38 140716544316288 [Note] WSREP: gcomm: connected 2016-09-01 16:41:38 140716544316288 [Note] WSREP: Changing maximum packet size to 64500, resulting msg size: 32636 2016-09-01 16:41:38 140716544316288 [Note] WSREP: Shifting CLOSED -> OPEN (TO: 0) 2016-09-01 16:41:38 140716544316288 [Note] WSREP: Opened channel 'example_cluster' 2016-09-01 16:41:38 140715987670784 [Note] WSREP: New COMPONENT: primary = yes, bootstrap = no, my_idx = 0, memb_num = 1 2016-09-01 16:41:38 140716544316288 [Note] WSREP: Waiting for SST to complete. 2016-09-01 16:41:38 140715987670784 [Note] WSREP: STATE_EXCHANGE: sent state UUID: e5a3bc45-701f-11e6-ba1c-471590fea490 2016-09-01 16:41:38 140715987670784 [Note] WSREP: STATE EXCHANGE: sent state msg: e5a3bc45-701f-11e6-ba1c-471590fea490 2016-09-01 16:41:38 140715987670784 [Note] WSREP: STATE EXCHANGE: got state msg: e5a3bc45-701f-11e6-ba1c-471590fea490 from 0 (MMN-0) 2016-09-01 16:41:38 140715987670784 [Note] WSREP: Quorum results: version = 4, component = PRIMARY, conf_id = 0, members = 1/1 (joined/total), act_id = 0, last_appl. = -1, protocols = 0/7/3 (gcs/repl/appl), group UUID = 900987cc-7003-11e6-b25f-de0a52317f1d 2016-09-01 16:41:38 140715987670784 [Note] WSREP: Flow-control interval: [16, 16] 2016-09-01 16:41:38 140715987670784 [Note] WSREP: Restored state OPEN -> JOINED (0) 2016-09-01 16:41:38 140715987670784 [Note] WSREP: Member 0.0 (MMN-0) synced with group. 2016-09-01 16:41:38 140716542806784 [Note] WSREP: New cluster view: global state: 900987cc-7003-11e6-b25f-de0a52317f1d:0, view# 1: Primary, number of nodes: 1, my index: 0, protocol version 3 2016-09-01 16:41:38 140715987670784 [Note] WSREP: Shifting JOINED -> SYNCED (TO: 0) 2016-09-01 16:41:38 140716544316288 [Note] WSREP: SST complete, seqno: 0 2016-09-01 16:41:38 140716544316288 [Note] InnoDB: Using mutexes to ref count buffer pool pages 2016-09-01 16:41:38 140716544316288 [Note] InnoDB: InnoDB: !!!!!!!! UNIV_DEBUG switched on !!!!!!!!! 2016-09-01 16:41:38 140716544316288 [Note] InnoDB: InnoDB: !!!!!!!! UNIV_SYNC_DEBUG switched on !!!!!!!!! 2016-09-01 16:41:38 140716544316288 [Note] InnoDB: The InnoDB memory heap is disabled 2016-09-01 16:41:38 140716 _______________________________________________ Mailing list: https://launchpad.net/~maria-discuss Post to : maria-discuss(a)lists.launchpad.net Unsubscribe : https://launchpad.net/~maria-discuss More help : https://help.launchpad.net/ListHelp

2 1

[Maria-discuss] TLS SNI support
by Felipe Gasper 03 Sep '16

03 Sep '16

Hi all, Has support for TLS SNI ever been discussed for MariaDB? This would allow hosting of multiple SSL certificates from the same server. It’s a boon in shared hosting environments. From the client’s end, at least, it would be trivial to implement. Doing it on the server would be trickier, but still pretty doable, I’d think? -Felipe Gasper

3 5

[Maria-discuss] 转发：failed to connect mariadb at addition node in MariaDB galera cluster
by 西门吹牛 02 Sep '16

02 Sep '16

SGksDQogIEkgZGVwbG95ZWQgdHdvIE1hcmlhREIgZ2FsZXJhIHZlcnNpb24gaW4gdHdvIG5vZGVzIHRvIGJ1aWxkIGNsdXN0ZXIuIEJ1dCBJIGNhbuKAmXQgY29ubmVjdCBNYXJpYURCIGluIHNlY29uZCBub2RlIGFzIHNlZW1zIHRoZSBwb3J0IGlzIG5vdCBjcmVhdGVkIGJ5IE1hcmlhREIgYmVjYXVzZSBsb29rcyBsaWtlIGl0IGlzIHN0dWNrIHNvbWVob3cuDQogIFZlcnNpb246IG15c3FsZCAxMC4xLjE3LU1hcmlhREItZGVidWcgVlMgZ2FsZXJhLTMtMjUuMy4xNw0KIA0KSSBzdGFydGVkIE1hcmlhREIgaW4gZmlyc3Qgbm9kZS4gU2VlbXMgZmluZS4gUG9ydCAzMzA3IHdhcyBjcmVhdGVkIGFuZCBJIGNhbiBsb2dpbiBNYXJpYWRiIGJ5IG15c3FsLg0KDQoNCiANCg0KDQpbcm9vdEBNTU4tMChSQ1AtNjkpIC9yb290L3Rlc3RdDQoNCiMgL2hvbWUvX3JjcGFkbWluL2Jpbi9tYXJpYWRiL2Jpbi9teXNxbGQgLS1kZWZhdWx0cy1leHRyYS1maWxlPS4vbW1uLm15LmNuZiAtLXdzcmVwLW5ldy1jbHVzdGVyIC0tZGVidWcNCg0KMjAxNi0wOS0wMSAxNjo0MTozNyAxNDA3MTY1NDQzMTYyODggW05vdGVdIC9ob21lL19yY3BhZG1pbi9iaW4vbWFyaWFkYi9iaW4vbXlzcWxkIChteXNxbGQgMTAuMS4xNy1NYXJpYURCLWRlYnVnKSBzdGFydGluZyBhcyBwcm9jZXNzIDE1MjQ4IC4uLg0KDQoyMDE2LTA5LTAxIDE2OjQxOjM4IDE0MDcxNjU0NDMxNjI4OCBbTm90ZV0gV1NSRVA6IFNldHRpbmcgd3NyZXBfcmVhZHkgdG8gMA0KDQoyMDE2LTA5LTAxIDE2OjQxOjM4IDE0MDcxNjU0NDMxNjI4OCBbTm90ZV0gV1NSRVA6IFJlYWQgbmlsIFhJRCBmcm9tIHN0b3JhZ2UgZW5naW5lcywgc2tpcHBpbmcgcG9zaXRpb24gaW5pdA0KDQoyMDE2LTA5LTAxIDE2OjQxOjM4IDE0MDcxNjU0NDMxNjI4OCBbTm90ZV0gV1NSRVA6IHdzcmVwX2xvYWQoKTogbG9hZGluZyBwcm92aWRlciBsaWJyYXJ5ICcvdXNyL2xpYjY0L2xpYmdhbGVyYV9zbW0uc28nDQoNCjIwMTYtMDktMDEgMTY6NDE6MzggMTQwNzE2NTQ0MzE2Mjg4IFtOb3RlXSBXU1JFUDogd3NyZXBfbG9hZCgpOiBHYWxlcmEgMy4xNyhyMCkgYnkgQ29kZXJzaGlwIE95IDxpbmZvQGNvZGVyc2hpcC5jb20+IGxvYWRlZCBzdWNjZXNzZnVsbHkuDQoNCjIwMTYtMDktMDEgMTY6NDE6MzggMTQwNzE2NTQ0MzE2Mjg4IFtOb3RlXSBXU1JFUDogQ1JDLTMyQzogdXNpbmcgaGFyZHdhcmUgYWNjZWxlcmF0aW9uLg0KDQoyMDE2LTA5LTAxIDE2OjQxOjM4IDE0MDcxNjU0NDMxNjI4OCBbTm90ZV0gV1NSRVA6IEZvdW5kIHNhdmVkIHN0YXRlOiA5MDA5ODdjYy03MDAzLTExZTYtYjI1Zi1kZTBhNTIzMTdmMWQ6MA0KDQoyMDE2LTA5LTAxIDE2OjQxOjM4IDE0MDcxNjU0NDMxNjI4OCBbTm90ZV0gV1NSRVA6IFBhc3NpbmcgY29uZmlnIHRvIEdDUzogYmFzZV9kaXIgPSAvbWFyaWFkYi87IGJhc2VfaG9zdCA9IE1NTi0wOyBiYXNlX3BvcnQgPSA0NTY3OyBjZXJ0LmxvZ19jb25mbGljdHMgPSBubzsgZGVidWcgPSBubzsgZXZzLmF1dG9fZXZpY3QgPSAwOyBldnMuZGVsYXlfbWFyZ2luID0gUFQxUzsgZXZzLmRlbGF5ZWRfa2VlcF9wZXJpb2QNCj0gUFQzMFM7IGV2cy5pbmFjdGl2ZV9jaGVja19wZXJpb2QgPSBQVDAuNVM7IGV2cy5pbmFjdGl2ZV90aW1lb3V0ID0gUFQxNVM7IGV2cy5qb2luX3JldHJhbnNfcGVyaW9kID0gUFQxUzsgZXZzLm1heF9pbnN0YWxsX3RpbWVvdXRzID0gMzsgZXZzLnNlbmRfd2luZG93ID0gNDsgZXZzLnN0YXRzX3JlcG9ydF9wZXJpb2QgPSBQVDFNOyBldnMuc3VzcGVjdF90aW1lb3V0ID0gUFQ1UzsgZXZzLnVzZXJfc2VuZF93aW5kb3cgPSAyOyBldnMudmlld19mb3JnZXRfdGltZW91dA0KPSBQVDI0SDsgZ2NhY2hlLmRpciA9IC9tYXJpYWRiLzsgZ2NhY2hlLmtlZXBfcGFnZXNfc2l6ZSA9IDA7IGdjYWNoZS5tZW1fc2l6ZSA9IDA7IGdjYWNoZS5uYW1lID0gL21hcmlhZGIvL2dhbGVyYS5jYWNoZTsgZ2NhY2hlLnBhZ2Vfc2l6ZSA9IDMwME07IGdjYWNoZS5zaXplID0gMzAwTTsgZ2NvbW0udGhyZWFkX3ByaW8gPSA7IGdjcy5mY19kZWJ1ZyA9IDA7IGdjcy5mY19mYWN0b3IgPSAxLjA7IGdjcy5mY19saW1pdCA9IDE2OyBnY3MuZmNfbWFzdGVyX3NsYXZlDQo9IG5vOyBnY3MubWF4X3BhY2tldF9zaXplID0gNjQ1MDA7IGdjcy5tYXhfdGhyb3R0bGUgPSAwLjI1OyBnY3MucmVjdl9xX2hhcmRfbGltaXQgPSA5MjIzMzcyMDM2ODU0Nzc1ODA3OyBnY3MucmVjdl9xX3NvZnRfbGltaXQgPSAwLjI1OyBnY3Muc3luY19kb25vciA9IG5vOyBnbWNhc3Quc2VnbWVudCA9IDA7IGdtY2FzdC52ZXJzaW9uID0gMDsgcGMuYW5ub3VuY2VfdGltZW91dCA9IFBUM1M7IHBjLmNoZWNrc3VtID0gZmFsc2U7IHBjLmlnbm9yZV9xdW9ydW0NCj0gZmFsc2U7IHBjLmlnbm9yZV9zYiA9IGZhbHNlOyBwYw0KDQoyMDE2LTA5LTAxIDE2OjQxOjM4IDE0MDcxNjAyOTYzNDMwNCBbTm90ZV0gV1NSRVA6IFNlcnZpY2UgdGhyZWFkIHF1ZXVlIGZsdXNoZWQuDQoNCjIwMTYtMDktMDEgMTY6NDE6MzggMTQwNzE2NTQ0MzE2Mjg4IFtOb3RlXSBXU1JFUDogQXNzaWduIGluaXRpYWwgcG9zaXRpb24gZm9yIGNlcnRpZmljYXRpb246IDAsIHByb3RvY29sIHZlcnNpb246IC0xDQoNCjIwMTYtMDktMDEgMTY6NDE6MzggMTQwNzE2NTQ0MzE2Mjg4IFtOb3RlXSBXU1JFUDogd3NyZXBfc3N0X2dyYWIoKQ0KDQoyMDE2LTA5LTAxIDE2OjQxOjM4IDE0MDcxNjU0NDMxNjI4OCBbTm90ZV0gV1NSRVA6IFN0YXJ0IHJlcGxpY2F0aW9uDQoNCjIwMTYtMDktMDEgMTY6NDE6MzggMTQwNzE2NTQ0MzE2Mjg4IFtOb3RlXSBXU1JFUDogJ3dzcmVwLW5ldy1jbHVzdGVyJyBvcHRpb24gdXNlZCwgYm9vdHN0cmFwcGluZyB0aGUgY2x1c3Rlcg0KDQoyMDE2LTA5LTAxIDE2OjQxOjM4IDE0MDcxNjU0NDMxNjI4OCBbTm90ZV0gV1NSRVA6IFNldHRpbmcgaW5pdGlhbCBwb3NpdGlvbiB0byA5MDA5ODdjYy03MDAzLTExZTYtYjI1Zi1kZTBhNTIzMTdmMWQ6MA0KDQoyMDE2LTA5LTAxIDE2OjQxOjM4IDE0MDcxNjU0NDMxNjI4OCBbTm90ZV0gV1NSRVA6IHByb3RvbmV0IGFzaW8gdmVyc2lvbiAwDQoNCjIwMTYtMDktMDEgMTY6NDE6MzggMTQwNzE2NTQ0MzE2Mjg4IFtOb3RlXSBXU1JFUDogVXNpbmcgQ1JDLTMyQyBmb3IgbWVzc2FnZSBjaGVja3N1bXMuDQoNCjIwMTYtMDktMDEgMTY6NDE6MzggMTQwNzE2NTQ0MzE2Mjg4IFtOb3RlXSBXU1JFUDogYmFja2VuZDogYXNpbw0KDQoyMDE2LTA5LTAxIDE2OjQxOjM4IDE0MDcxNjU0NDMxNjI4OCBbTm90ZV0gV1NSRVA6IGdjb21tIHRocmVhZCBzY2hlZHVsaW5nIHByaW9yaXR5IHNldCB0byBvdGhlcjowIA0KDQoyMDE2LTA5LTAxIDE2OjQxOjM4IDE0MDcxNjU0NDMxNjI4OCBbV2FybmluZ10gV1NSRVA6IGFjY2VzcyBmaWxlKC9tYXJpYWRiLy9ndndzdGF0ZS5kYXQpIGZhaWxlZChObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5KQ0KDQoyMDE2LTA5LTAxIDE2OjQxOjM4IDE0MDcxNjU0NDMxNjI4OCBbTm90ZV0gV1NSRVA6IHJlc3RvcmUgcGMgZnJvbSBkaXNrIGZhaWxlZA0KDQoyMDE2LTA5LTAxIDE2OjQxOjM4IDE0MDcxNjU0NDMxNjI4OCBbTm90ZV0gV1NSRVA6IEdNQ2FzdCB2ZXJzaW9uIDANCg0KMjAxNi0wOS0wMSAxNjo0MTozOCAxNDA3MTY1NDQzMTYyODggW05vdGVdIFdTUkVQOiAoZTVhMzJkM2MsICd0Y3A6Ly8wLjAuMC4wOjQ1NjcnKSBsaXN0ZW5pbmcgYXQgdGNwOi8vMC4wLjAuMDo0NTY3DQoNCjIwMTYtMDktMDEgMTY6NDE6MzggMTQwNzE2NTQ0MzE2Mjg4IFtOb3RlXSBXU1JFUDogKGU1YTMyZDNjLCAndGNwOi8vMC4wLjAuMDo0NTY3JykgbXVsdGljYXN0OiAsIHR0bDogMQ0KDQoyMDE2LTA5LTAxIDE2OjQxOjM4IDE0MDcxNjU0NDMxNjI4OCBbTm90ZV0gV1NSRVA6IEVWUyB2ZXJzaW9uIDANCg0KMjAxNi0wOS0wMSAxNjo0MTozOCAxNDA3MTY1NDQzMTYyODggW05vdGVdIFdTUkVQOiBnY29tbTogYm9vdHN0cmFwcGluZyBuZXcgZ3JvdXAgJ2V4YW1wbGVfY2x1c3RlcicNCg0KMjAxNi0wOS0wMSAxNjo0MTozOCAxNDA3MTY1NDQzMTYyODggW05vdGVdIFdTUkVQOiBzdGFydF9wcmltIGlzIGVuYWJsZWQsIHR1cm4gb2ZmIHBjX3JlY292ZXJ5DQoNCjIwMTYtMDktMDEgMTY6NDE6MzggMTQwNzE2NTQ0MzE2Mjg4IFtOb3RlXSBXU1JFUDogTm9kZSBlNWEzMmQzYyBzdGF0ZSBwcmltDQoNCjIwMTYtMDktMDEgMTY6NDE6MzggMTQwNzE2NTQ0MzE2Mjg4IFtOb3RlXSBXU1JFUDogdmlldyh2aWV3X2lkKFBSSU0sZTVhMzJkM2MsMSkgbWVtYiB7DQoNCiAgICAgICAgZTVhMzJkM2MsMA0KDQp9IGpvaW5lZCB7DQoNCn0gbGVmdCB7DQoNCn0gcGFydGl0aW9uZWQgew0KDQp9KQ0KDQoyMDE2LTA5LTAxIDE2OjQxOjM4IDE0MDcxNjU0NDMxNjI4OCBbTm90ZV0gV1NSRVA6IHNhdmUgcGMgaW50byBkaXNrDQoNCjIwMTYtMDktMDEgMTY6NDE6MzggMTQwNzE2NTQ0MzE2Mjg4IFtOb3RlXSBXU1JFUDogZGlzY2FyZGluZyBwZW5kaW5nIGFkZHIgd2l0aG91dCBVVUlEOiB0Y3A6Ly8xNjkuMjU0LjAuNDo0NTY3DQoNCjIwMTYtMDktMDEgMTY6NDE6MzggMTQwNzE2NTQ0MzE2Mjg4IFtOb3RlXSBXU1JFUDogZGlzY2FyZGluZyBwZW5kaW5nIGFkZHIgcHJvdG8gZW50cnkgMHg1NjUyYjAzNTJlZjANCg0KMjAxNi0wOS0wMSAxNjo0MTozOCAxNDA3MTY1NDQzMTYyODggW05vdGVdIFdTUkVQOiBkaXNjYXJkaW5nIHBlbmRpbmcgYWRkciB3aXRob3V0IFVVSUQ6IHRjcDovLzE2OS4yNTQuMC41OjQ1NjcNCg0KMjAxNi0wOS0wMSAxNjo0MTozOCAxNDA3MTY1NDQzMTYyODggW05vdGVdIFdTUkVQOiBkaXNjYXJkaW5nIHBlbmRpbmcgYWRkciBwcm90byBlbnRyeSAweDU2NTJiMDM1YjcyMA0KDQoyMDE2LTA5LTAxIDE2OjQxOjM4IDE0MDcxNjU0NDMxNjI4OCBbTm90ZV0gV1NSRVA6IGRpc2NhcmRpbmcgcGVuZGluZyBhZGRyIHdpdGhvdXQgVVVJRDogdGNwOi8vMTY5LjI1NC4wLjY6NDU2Nw0KDQoyMDE2LTA5LTAxIDE2OjQxOjM4IDE0MDcxNjU0NDMxNjI4OCBbTm90ZV0gV1NSRVA6IGRpc2NhcmRpbmcgcGVuZGluZyBhZGRyIHByb3RvIGVudHJ5IDB4NTY1MmIwMzYzZWEwDQoNCjIwMTYtMDktMDEgMTY6NDE6MzggMTQwNzE2NTQ0MzE2Mjg4IFtOb3RlXSBXU1JFUDogZ2NvbW06IGNvbm5lY3RlZA0KDQoyMDE2LTA5LTAxIDE2OjQxOjM4IDE0MDcxNjU0NDMxNjI4OCBbTm90ZV0gV1NSRVA6IENoYW5naW5nIG1heGltdW0gcGFja2V0IHNpemUgdG8gNjQ1MDAsIHJlc3VsdGluZyBtc2cgc2l6ZTogMzI2MzYNCg0KMjAxNi0wOS0wMSAxNjo0MTozOCAxNDA3MTY1NDQzMTYyODggW05vdGVdIFdTUkVQOiBTaGlmdGluZyBDTE9TRUQgLT4gT1BFTiAoVE86IDApDQoNCjIwMTYtMDktMDEgMTY6NDE6MzggMTQwNzE2NTQ0MzE2Mjg4IFtOb3RlXSBXU1JFUDogT3BlbmVkIGNoYW5uZWwgJ2V4YW1wbGVfY2x1c3RlcicNCg0KMjAxNi0wOS0wMSAxNjo0MTozOCAxNDA3MTU5ODc2NzA3ODQgW05vdGVdIFdTUkVQOiBOZXcgQ09NUE9ORU5UOiBwcmltYXJ5ID0geWVzLCBib290c3RyYXAgPSBubywgbXlfaWR4ID0gMCwgbWVtYl9udW0gPSAxDQoNCjIwMTYtMDktMDEgMTY6NDE6MzggMTQwNzE2NTQ0MzE2Mjg4IFtOb3RlXSBXU1JFUDogV2FpdGluZyBmb3IgU1NUIHRvIGNvbXBsZXRlLg0KDQoyMDE2LTA5LTAxIDE2OjQxOjM4IDE0MDcxNTk4NzY3MDc4NCBbTm90ZV0gV1NSRVA6IFNUQVRFX0VYQ0hBTkdFOiBzZW50IHN0YXRlIFVVSUQ6IGU1YTNiYzQ1LTcwMWYtMTFlNi1iYTFjLTQ3MTU5MGZlYTQ5MA0KDQoyMDE2LTA5LTAxIDE2OjQxOjM4IDE0MDcxNTk4NzY3MDc4NCBbTm90ZV0gV1NSRVA6IFNUQVRFIEVYQ0hBTkdFOiBzZW50IHN0YXRlIG1zZzogZTVhM2JjNDUtNzAxZi0xMWU2LWJhMWMtNDcxNTkwZmVhNDkwDQoNCjIwMTYtMDktMDEgMTY6NDE6MzggMTQwNzE1OTg3NjcwNzg0IFtOb3RlXSBXU1JFUDogU1RBVEUgRVhDSEFOR0U6IGdvdCBzdGF0ZSBtc2c6IGU1YTNiYzQ1LTcwMWYtMTFlNi1iYTFjLTQ3MTU5MGZlYTQ5MCBmcm9tIDAgKE1NTi0wKQ0KDQoyMDE2LTA5LTAxIDE2OjQxOjM4IDE0MDcxNTk4NzY3MDc4NCBbTm90ZV0gV1NSRVA6IFF1b3J1bSByZXN1bHRzOg0KDQogICAgICAgIHZlcnNpb24gICAgPSA0LA0KDQogICAgICAgIGNvbXBvbmVudCAgPSBQUklNQVJZLA0KDQogICAgICAgIGNvbmZfaWQgICAgPSAwLA0KDQogICAgICAgIG1lbWJlcnMgICAgPSAxLzEgKGpvaW5lZC90b3RhbCksDQoNCiAgICAgICAgYWN0X2lkICAgICA9IDAsDQoNCiAgICAgICAgbGFzdF9hcHBsLiA9IC0xLA0KDQogICAgICAgIHByb3RvY29scyAgPSAwLzcvMyAoZ2NzL3JlcGwvYXBwbCksDQoNCiAgICAgICAgZ3JvdXAgVVVJRCA9IDkwMDk4N2NjLTcwMDMtMTFlNi1iMjVmLWRlMGE1MjMxN2YxZA0KDQoyMDE2LTA5LTAxIDE2OjQxOjM4IDE0MDcxNTk4NzY3MDc4NCBbTm90ZV0gV1NSRVA6IEZsb3ctY29udHJvbCBpbnRlcnZhbDogWzE2LCAxNl0NCg0KMjAxNi0wOS0wMSAxNjo0MTozOCAxNDA3MTU5ODc2NzA3ODQgW05vdGVdIFdTUkVQOiBSZXN0b3JlZCBzdGF0ZSBPUEVOIC0+IEpPSU5FRCAoMCkNCg0KMjAxNi0wOS0wMSAxNjo0MTozOCAxNDA3MTU5ODc2NzA3ODQgW05vdGVdIFdTUkVQOiBNZW1iZXIgMC4wIChNTU4tMCkgc3luY2VkIHdpdGggZ3JvdXAuDQoNCjIwMTYtMDktMDEgMTY6NDE6MzggMTQwNzE2NTQyODA2Nzg0IFtOb3RlXSBXU1JFUDogTmV3IGNsdXN0ZXIgdmlldzogZ2xvYmFsIHN0YXRlOiA5MDA5ODdjYy03MDAzLTExZTYtYjI1Zi1kZTBhNTIzMTdmMWQ6MCwgdmlldyMgMTogUHJpbWFyeSwgbnVtYmVyIG9mIG5vZGVzOiAxLCBteSBpbmRleDogMCwgcHJvdG9jb2wgdmVyc2lvbiAzDQoNCjIwMTYtMDktMDEgMTY6NDE6MzggMTQwNzE1OTg3NjcwNzg0IFtOb3RlXSBXU1JFUDogU2hpZnRpbmcgSk9JTkVEIC0+IFNZTkNFRCAoVE86IDApDQoNCjIwMTYtMDktMDEgMTY6NDE6MzggMTQwNzE2NTQ0MzE2Mjg4IFtOb3RlXSBXU1JFUDogU1NUIGNvbXBsZXRlLCBzZXFubzogMA0KDQoyMDE2LTA5LTAxIDE2OjQxOjM4IDE0MDcxNjU0NDMxNjI4OCBbTm90ZV0gSW5ub0RCOiBVc2luZyBtdXRleGVzIHRvIHJlZiBjb3VudCBidWZmZXIgcG9vbCBwYWdlcw0KDQoyMDE2LTA5LTAxIDE2OjQxOjM4IDE0MDcxNjU0NDMxNjI4OCBbTm90ZV0gSW5ub0RCOiAgSW5ub0RCOiAhISEhISEhISBVTklWX0RFQlVHIHN3aXRjaGVkIG9uICEhISEhISEhIQ0KDQoyMDE2LTA5LTAxIDE2OjQxOjM4IDE0MDcxNjU0NDMxNjI4OCBbTm90ZV0gSW5ub0RCOiAgSW5ub0RCOiAhISEhISEhISBVTklWX1NZTkNfREVCVUcgc3dpdGNoZWQgb24gISEhISEhISEhDQoNCjIwMTYtMDktMDEgMTY6NDE6MzggMTQwNzE2NTQ0MzE2Mjg4IFtOb3RlXSBJbm5vREI6IFRoZSBJbm5vREIgbWVtb3J5IGhlYXAgaXMgZGlzYWJsZWQNCg0KMjAxNi0wOS0wMSAxNjo0MTozOCAxNDA3MTY[truncated for moderation]

2 1

[Maria-discuss] Upgrade error: mariadb 10.1.16 to 10.1.17
by Erik de Waard 01 Sep '16

01 Sep '16

Hello, When upgrading from 10.1.16 to 10.1.17 on Debian Jessie i've received the following error: aptitude upgrade <snip> dpkg: error processing package mariadb-server-10.1 (--configure): subprocess installed post-installation script returned error exit status 1 Processing triggers for libc-bin (2.19-18+deb8u4) ... Errors were encountered while processing: mariadb-server-10.1 E: Sub-process /usr/bin/dpkg returned an error code (1) Failed to perform requested operation on package. Trying to recover: Setting up mariadb-server-10.1 (10.1.17+maria-1~jessie) ... dpkg: error processing package mariadb-server-10.1 (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: mariadb-server-10.1 Current status: 0 updates [-14] <snip> /var/log/syslog mysqld_safe[44689]: ERROR: 1136 Column count doesn't match value count at row 1 Was able to fix by running. /usr/sbin/mysqld --skip-grant --general-log & And running the upgrade again. See attached full logs.

2 1

[Maria-discuss] New Question: AES_ENCRYPT() and AES_DECRYPT() with other than ECB mode?
by AskMonty KB 01 Sep '16

01 Sep '16

Hello, A new question has been asked in "MariaDB Community" by w3goodies.com_64477. Please answer it at http://mariadb.com/kb/en/aes_encrypt-and-aes_decrypt-with-other-than-ecb-mo… as the person asking the question may not be subscribed to the mailing list. -------------------------------- Since MySQL 5.6.17, MySQL supports block_encryption_mode to change encryption mode from ECB to other modes like 256-CBC http://dev.mysql.com/doc/refman/5.7/en/server-system-variables.html#sysvar_… I think MariaDB currently only supports 128-ECB for AES_ENCRYPT() and AES_DECRYPT(), will there be update in MariaDB to merge this block_encryption_mode feature any soon? -------------------------------- To view or answer this question please visit: http://mariadb.com/kb/en/aes_encrypt-and-aes_decrypt-with-other-than-ecb-mo…

1 0

[Maria-discuss] InnoDB plugin maturity
by Ian Gilfillan 01 Sep '16

01 Sep '16

If you look at the list of plugin maturities, say with: SELECT plugin_name,plugin_version,plugin_maturity FROM information_schema.plugins ORDER BY plugin_name; I notice that in 10.1, InnoDB/XtraDB is listed as Gamma (changed from Beta in 10.1.13), while in 10.0, with the same version of XtraDB, it's listed as Stable. What's the basis of the distinction between the two, especially since 10.1 itself is a stable release? It seems strange to have InnoDB listed as the same maturity as Spider :)

2 1