- discuss - lists.mariadb.org

[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

Re: [Maria-discuss] Don't replicate procedures in the mysql database
by Federico Razzoli 01 Sep '16

01 Sep '16

I never used replicate_ignore_db='mysql'. But I know some people does. Did you check if it has side effects? Federico -------------------------------------------- Mer 31/8/16, Игорь Пашев <pashev.igor(a)gmail.com> ha scritto: Oggetto: Re: [Maria-discuss] Don't replicate procedures in the mysql database A: "MariaDB discuss" <maria-discuss(a)lists.launchpad.net> Data: Mercoledì 31 agosto 2016, 23:39 Thanks to everyone Here is the solution: On the slave: Replicate_Ignore_DB: mysql Replicate_Do_Table: Replicate_Ignore_Table: Replicate_Wild_Do_Table: foo.% Replicate_Wild_Ignore_Table: On the master: USE mysql; CREATE PROCEDURE whatever() BEGIN END; _______________________________________________ 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] Don't replicate procedures in the mysql database
by Игорь Пашев 31 Aug '16

31 Aug '16

Hi all, I'm using multi-source replication with "white list" options only: foo.replicate_wild_do_table = foo.% foo.replicate_ignore_table = foo.beep foo.replicate_ignore_table = foo.tmp The masters are writing row-based binary logs as is (no filtering at masters). This works almost as expected: only the `foo` database gets updates, the mentioned tables are ignored. The `mysql` database does not get updates, even when I run GRANT / REVOKE on the masters quite often. But when I create a procedure on the master it get propagated to the slave: When I execute `CREATE PROCEDURE mysql.bar` on the master, this procedure appears on the slave. How could I avoid that? Did I miss some options? Is this a bug?

4 5

[Maria-discuss] New Question: MONyog Cluster Monitoring
by AskMonty KB 31 Aug '16

31 Aug '16

Hello, A new question has been asked in "MariaDB FAQ" by palash.harchandani93_43595. Please answer it at http://mariadb.com/kb/en/monyog-cluster-monitoring/ as the person asking the question may not be subscribed to the mailing list. -------------------------------- Is it possible to see all the monitoring information for galera cluster together..for eg In charts we get collected information of all the nodes of a cluster? -------------------------------- To view or answer this question please visit: http://mariadb.com/kb/en/monyog-cluster-monitoring/

1 0

[Maria-discuss] optimize table wait table level lock in MairaDB 10.1.16 ?
by Ljr Yang 31 Aug '16

31 Aug '16

Hi, all Today, we use optimize table in MariaDB 10.1.16. Table test01 have about 2 millions records. session 1: optimize table test01; session 2: select count(*) from test01 ; when session 1 run, In processlist session 2 state: Waiting FOR TABLE LEVEL LOCK we had set innodb_defragment=1 in my.cnf ,but run optimize table still have table lock？ reference link: https://mariadb.com/kb/en/mariadb/defragmenting-innodb-tablespaces/ -- Ljr

2 1