So I recently updated to mysql 5.7 from 5.1, and now I notice on this version the up/down arrows do not cycle through the whole history. According to the mysql docs, certain commands related to passwords are no longer logged, but in my case there seems to be a lot more than that. Most of my queries are not logged at all and they are just simple queries like:
select table1.email, table1.password, table2.id, table2.ip from table1 join table2 on table1.property1 = table2.property2 order by table2.id;
I eventually figured out this is because I have a column called 'password' in one of my tables and mysql will not log this query at all just because it contains the word password. I've gone through a lot of googling, bug reports, mysql docs but there is not a single piece of information about disabling this history ignore behavior, or at least removing some rules from it, there's only instructions on how to add even more rules.
Is there any know solution for this, or do I have to rename my columns and change my stored procedures?
This is not a bug, this is a feature.
mysql ignores for logging purposes statements that match any pattern in the “ignore” list. By default, the pattern list is "*IDENTIFIED*:*PASSWORD*", to ignore statements that refer to passwords.
https://dev.mysql.com/doc/refman/5.7/en/mysql-logging.html
You can add patterns to the list, but not remove them.
https://bugs.mysql.com/bug.php?id=71987
Related
OS: W10.
This question is specifically about what's possible in MariaDB, specially version "Ver 15.1 Distrib 10.7.3-MariaDB".
Edit
From another SO site I have found that from 10.3.4 MariaDB does in fact implement "temporal tables". Not clear yet whether this provides a solution.
I want to implement a way of having a "last modified" timestamp for a database, i.e. which shows when the last INSERT or DELETE or UPDATE occurred, regardless of the table where it happened. I found this, which looked promising... but then some comments there about InnoDB and information_schema.tables.update_time led me to do an experiment.
Contrary to what is asserted in some places about update_time always being NULL in InnoDB tables, this does not seem to be the case with what I've got. Unfortunately, the comment there about this value being set to NULL whenever the server starts does appear to be true.
Elsewhere I read that newer versions of MariaDB, pulling away from vanilla MySQL, do in fact implement some sort of history of changes.
I'm currently working on the assumption that I shall have to implement an ON_UPATE trigger for every table, and then get values for each of these and find the most recent, in order to determine the "last modified" time for the whole database.
Is there any other possibility with this version of MariaDB?
Edit
In fact I have provided an answer which works for my use case on another SO site (when I added this link as an answer here that answer was then deleted by a mod - but in reality some might find it useful).
just make a table that has all the table names and a timestamp column.
then on the ON_UPATE trigger, just update the tablename record.
this way, you have central table which has the timestamps, dont do any hacks.
keep it simple.
use this
I have two mysql databases that I'd like to keep in sync. When I run
show create trigger tr_del_EmailHash;
from a mysqli connection from a local web page I get slightly different output from each database in that one returns the trigger name in single quotes like this:
CREATE trigger `tr_del_EmailHash` before DELETE
...
and the other returns the trigger name without quotes like this:
CREATE trigger tr_del_EmailHash before DELETE
...
Since I'm trying to store these in source control and be able to diff schema across platforms, this difference is very undesirable. The mysqld.cnf files and the mysql server variables are the same on each server, so I'm at a loss for where to look for what controls whether or not the name of a trigger gets quoted or not by "show create trigger" queries. Can anyone provide some helpful suggestions as to where I should be looking or where this can be adjusted?
The quoting behaviour for show create-statements is controlled with the sql_quote_show_create configuration setting:
If enabled (the default), the server quotes identifiers for SHOW CREATE TABLE and SHOW CREATE DATABASE statements. If disabled, quoting is disabled. This option is enabled by default so that replication works for identifiers that require quoting.
Specifically for triggers, this unfortunately only works for MySQL 8, and only applies to the trigger and table name, not the trigger body. Earlier versions will quote the names as you entered them (which might be under your control, and especially involves the body anyway). This may cause trouble though if you mix MySQL 8 and earlier versions (where some modify the code, others don't), so you may have to decide for one congruent naming schema and adjust that setting accordingly.
I'm not able to update values on tables present on my database using MySQL Workbench (or equivalent software such as Toad Edge):
The tables are read-only although primary key is present.
Only very few times the "read only" label is not present and MySQL Workbench lets me update table fields values, but if this occurs, as soon as I run another query (or if I run the same query twice), the "read only" label appears again.
This is all depends of the kind of query that you execute. If it's a simple one table query with simple WHERE command, then it should not be marked as "Read Only". However if the query contains an aggregation, group by or joins, then it will be marked as read only as trying to update the showed rows should be considered ambiguous.
At least Workbench allows editing on simple WHERE filters by default. Other IDEs, like SQLYog, marks any manually queried results as Read Only. However it could be overridden and it does an evaluation if it's safe to direct edit the data, if not, it stays as Read Only.
If this is not case, then it could be that the user that you are using to connect do not have UPDATE or INSERT rights.
I work with Yii 1.1.13.
Is it good to call a table group? (In MySQL GROUP is a keyword, as used in "GROUP BY")
It's probably a bad idea, while some RDBMS support applying keywords to fields or tables (and accessing them using [] i.e select [group] from tbl ) it doesn't mean you should.
We recently have an issue where we had a field name group in one of our main tables, this was on a DB2 engine and we never had an issue, but then we moved our DataWarehouse to a PostgreSQL's fork named Greenplum and it didn't support a keyword as name for a field, so the DBA's were forced to change the field name in the migration and several services and reports failed until the code was changed. Production supported was impacted and everybody was mad/crazy about this.
It is my recommendation to avoid it, and remember anything that can go wrong, will go wrong
Does anyone know of a way to embed comments in MySQL statements? When I search for mysql and comments I get only ways to put comments in tables, etc
The idea, if I implement this the way my boss wants it, is to prepend the user id to the statement apparently so that when MySQL is analyzed later (via the binary log) we know who did what.
Example:
SELECT id
FROM customer
WHERE handle='JBH'
Would now show up as:
-- user:jwilkie
SELECT id
FROM customer
WHERE handle='JBH'
(or similar)
EDIT FOR CLARITY: The reason for this is that we have perl modules that are interfacing with MySQL and we are retrieving the user id by reading $ENV{USER} (which in this case is "jwilkie"). It is a situation where we have one MySQL user defined but multiple people running the perl mod.
Does anyone have experience with this? Many many thanks! Jane
Normally, comments are stripped before the SQL statement is recorded in the binary log. However, a nasty workaround is to pretend that ypur comment contains syntax for some future version of MySQL - eg. 9.99.99:
/*!99999 user:jwilkie */ insert into tbl values (yyy);
These comments will then be passed through into the binary log.
If you have control over the SQL queries being generated, then you should be able to embed comments in them programatically in your query builder.
Select queries don't go in the binary log, but the comments may make it into the slow query log, general query log, etc.
Here's a blog post from Percona that touches on the subject a bit, specifically in the context of mk-query-digest. It might help:
http://www.mysqlperformanceblog.com/2010/07/05/mk-query-digest-query-comments-and-the-query-cache/