logs archiveChat DB / Freenode / #mysql / 2015 / September / 29 / 1
linforpros
Hi, fresh installation of community mysql server on fedora 22. mysql_secure_installation does not accept a password giving this output: http://pastebin.com/bSByUSvM How can I circumvent it?
snoyes
linforpros: which version is the MySQL server?
or rather, which version of the client?
linforpros
5.6.26
snoyes
that "unknown option" is what I'd expect from a version older than 5.6.12
linforpros
snoyes: secure_installation script was the first thing I did after starting "systemdctl start mysqld.service". The logs in journalctl is recomending to run this script
snoyes
linforpros: Are you calling mysql_secure_installation, or is it picking up that option from the [client] section of my.cnf?
if the latter, comment it out for now, run the secure installation, and then put it back
and probably file a bug
and/or check that the package you installed has the latest mysql client, not using an old client with the new server
linforpros
client section of my.cnf which has !include stanza looks like that: http://pastebin.com/eDhHQzWf
green-
I'm hoping to add partitioning by DATETIME column to a very large table I'm managing, but just realized that means adding the DATETIME column to the PRIMARY KEY, which is currently an auto_incremement BIGINT column. Will the expense of adding the datetime col to the PK potentially outweigh the benefits of partitioning?
aeiou
when you run SET foreign_key_checks = 0; - will this prevent ON UPDATE CASCADE from happening or just prevent warnings about FK errors
asti
hello again. How can I say something like this `select * from X where truncate(x.url, "www", "http://", "/$") in (some list)`?
snoyes
there's TRIM(LEADING 'foo' FROM 'foobar')
so, TRIM(LEADING 'www' FROM TRIM(LEADING 'http://' FROM TRIM(TRAILING '/' FROM x.url))
green-: have you considered making the auto_increment column not pk?
green-
snoyes: yeah just did that with the test schema i just loaded. made the auto_incremenet col just a column, and the PK is now a three column key which is (DATETIME, INT, INT) -- using two other important INT columns in the table
snoyes
aeiou: it should disable cascading too, but you could test that
green-
snoyes: my default thought process is to make the PK column as lean as possible, but I'm not sure that's grounded in any good reason. The three column key that is now the PK existed as a separate index anyway, so I'm hoping this produces no additional expense/overhead (and perhaps even less).
snoyes
yes, you want the pk small, because InnoDB stores a copy of the pk value with each secondary index
aeiou
snoyes: where could i find this in the docs?
green-
snoyes: so then does the idea of a PK that is (DATETIME, INT, INT) sound inherently problematic in a table with billions of records?
next »