Subscribe: Comments for MySQL Performance Blog
http://www.mysqlperformanceblog.com/comments/feed/
Added By: Feedage Forager Feedage Grade A rated
Language: English
Tags:
affect performance  audit log  audit  bare metal  comment  data  log plugin  log policy  log  meltdown  mysql  peter  plugin  server  week 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Comments for MySQL Performance Blog

Comments for Percona Database Performance Blog





Last Build Date: Mon, 22 Jan 2018 23:00:46 +0000

 



Comment on Upgrading to MySQL 5.7? Beware of the new STRICT mode by Georgi Todorov

Mon, 22 Jan 2018 23:00:46 +0000

Thank you Alexander! Helpful article.



Comment on Why You Should Avoid Using “CREATE TABLE AS SELECT” Statement by Federico

Sun, 21 Jan 2018 21:39:04 +0000

It is also interesting to read this comment in the code: https://github.com/mysql/mysql-server/blob/f5ed5d58ffae0ff4c668830376faa411987915a1/sql/handler.cc#L1309 The scary part is: "This diversity makes it hard to say what will happen if by chance a stored function is invoked during a DDL -- whether any modifications it makes will be committed or not is not clear. Fortunately, SQL grammar of few DDLs allows invocation of a stored function."



Comment on This Week in Data with Colin Charles 24: more Meltdown, FOSDEM, Slack and reminiscing by Peter Laursen

Sat, 20 Jan 2018 12:20:46 +0000

Sorry, I messed up geography. Korea is not in SE Asia - rather in NE Asia. And I am not an American! (I recall that Mark Twain once said, that God invented war for Americans to learn geography! But I am no better it seems :-) )



Comment on This Week in Data with Colin Charles 24: more Meltdown, FOSDEM, Slack and reminiscing by Peter Laursen

Sat, 20 Jan 2018 12:14:09 +0000

I think that if anyone in the world has the financial muscels to challenge the dominance of Amazon (and to some extend Microsoft) in this business segment, it is Alibaba. They will probably focus on their homeland and East Asian countries for a start. SE Asia (Philipinnes, Korea, Indonesia), Russia, India and Australia are probably next. I don't foresee that they will become very big is the US nor Europe in near future, but if their techncial solutions develops and pricing and support are competetive, it will happen sonner or later. And maybe sooner! This is an almost complete "plugin replacement" for Amazon RDS and I welcome the competition.



Comment on Does the Meltdown Fix Affect Performance for MySQL on Bare Metal? by Vadim Tkachenko

Fri, 19 Jan 2018 19:31:17 +0000

At this time there is NO Spectre fixes available for Ubuntu, despite wide range of confusing claims you may find in Internet. We are looking if we can get data for CentOS, but most our bare metal servers are running Ubuntu.



Comment on MongoDB Consistent Backups by Prashant

Fri, 19 Jan 2018 11:59:22 +0000

does it backup in native format or in bson format?



Comment on Does the Meltdown Fix Affect Performance for MySQL on Bare Metal? by dsa dsad

Fri, 19 Jan 2018 10:26:38 +0000

what about spectre? Spectre is the one makes it hit hard.



Comment on Percona Server audit log plugin best practices by Peter Duffy

Thu, 18 Jan 2018 14:32:54 +0000

(correction - I changed audit_log_policy to "QUERIES", not "QUERY")



Comment on Percona Server audit log plugin best practices by Peter Duffy

Thu, 18 Jan 2018 14:31:43 +0000

I've been trying the audit_log plugin for about a week, and my experience has been fairly negative. I was concerned about the amount of data which would be produced if I installed the plugin on a production server, so I started by installing it on a test server with a fairly low throughput. All seemed well at first - but then I changed the variable "audit_log_policy" from "ALL" to "QUERY", and soon afterwards, the users of the server reported that they could not contact the server any more. When we checked, we found that there was a vast number of connections which appeared to be hanging. The obvious next step was to reboot the server - but as an experiment, I changed audit_log_policy to "NONE" - and everything immediately started working again. The problem was too closely synchronised with the changes to the plugin variable for it to be a coincidence - and on this basis, it's highly unlikely that we'll be trying the audit_log plugin again.



Comment on Logging Deadlock errors by Roman Borysenko

Thu, 18 Jan 2018 12:57:59 +0000

Should `pt-deadlock-logger` be run with Cron to get deadlocks info constantly or `--daemonize` option would be of help?