- discuss - lists.mariadb.org

[Maria-discuss] Database Platform Migration
by Suresh Rajagopal 10 Sep '16

10 Sep '16

Hi, How to migrate mysql 5.0 database from darwin to Linux? Database size is close to 1 TB Thanks Suresh Rajagopal

1 0

[Maria-discuss] Spider Nodes
by Suresh Rajagopal 10 Sep '16

10 Sep '16

Hi, What is best place to keep spider nodes ? Dedicated Physical Servers or Virtual Machines or Backend Nodes Backend nodes are physical servers with SSD. ThanksSuresh Rajagopal

1 0

[Maria-discuss] Reg Audit Trail Implementation
by Karthick Subramanian 08 Sep '16

08 Sep '16

All, Before I reinvent a wheel again, thought of checking with you experts whether any recommendation or suggestion for implementing audit trail feature for your database. I am looking for any open source product/tool for this purpose. I thought of exploring audit plugin, but I am not sure whether we can enable audit trail for the data changes in a tables. For example: *ORDER table:* ORDER_ID PRODUCT_ID QTY ORDER_DATE SHIP_DATE DELIVERY_DATE DELIVERY_ADDRESS Any changes on the above table's data (rows), we need to capture the audit trail like TABLE_NAME,COLUMN_NAME,OLD_VALUE,NEW_VALUE,CHANGE_DATE,CHANGE_BY,HOST,APP,MODULE etc. Thank you, Karthick

2 1

[Maria-discuss] handling of mixed case roles
by Robin Peiremans 05 Sep '16

05 Sep '16

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) This e-mail and any attached files are confidential and may be legally privileged. If you are not the addressee, any disclosure, reproduction, copying, distribution, or other dissemination or use of this communication is strictly prohibited. If you have received this transmission in error please notify KBC immediately and then delete this e-mail. KBC does not accept liability for the correct and complete transmission of the information, nor for any delay or interruption of the transmission, nor for damages arising from the use of or reliance on the information. All e-mail messages addressed to, received or sent by KBC or KBC employees are deemed to be professional in nature. Accordingly, the sender or recipient of these messages agrees that they may be read by other KBC employees than the official recipient or sender in order to ensure the continuity of work-related activities and allow supervision thereof.

2 2

[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