Skip Menu | Logged in as guest | Logout
 
Ticket metadata
Id: 3524
Status: resolved
Priority: 3/0
Queue: vdt-support

Fixed in: 1.10.1e
Fix scheduled: CUR

Owner: Tim Cartwright
Requestors: greenc@fnal.gov
Cc:
AdminCc:

More about greenc@fnal.gov
Comments about this user:
No comment entered about this user
This user's 10 highest priority tickets:
Groups this user belongs to:
  • Everyone
  • Unprivileged

New reminder:

Created: Tue May 13 13:56:03 2008
Starts: Not set
Started: Tue May 13 16:18:00 2008
Last Contact: Fri Jul 11 11:13:28 2008
Due: Not set
Closed: Fri Aug 01 11:44:49 2008
Updated: Fri Aug 01 11:44:58 2008 by cat



History Brief headersFull headers
CC: Philippe Canal <pcanal@fnal.gov>
Subject: More explanation of MySQL configuration option requests.
Date: Tue, 13 May 2008 11:43:05 -0500
To: Alain Roy <roy@cs.wisc.edu>, John Weigand <weigand@fnal.gov>, Tim Cartwright <cat@cs.wisc.edu>
From: Chris Green <greenc@fnal.gov>
Download (untitled) / with headers
text/plain 4.5k
Hi,

Please see attached HTML. Note that the options in green are those
recommended by MySQL for a "small" memory machine, say 512MB. Gratia
does not mind if they are optimized for larger (or smaller) systems,
but they should be set to *something*. Options that are *absolutely
necessary* for correct gratia operation are colored in red, and
innodb_flush_log_at_trx_commit is strongly desired in order to
minimize the chances of corruption and increase the chances of being
able to diagnose and fix it.

Please let me know if you have any remaining questions or problems
with these configuration options.

Thanks,
Chris.

--
Chris Green <greenc@fnal.gov>, FNAL CD/SCF/GRID; 'phone (630) 840-2167.
IRC: greenc@jabber.fnal.gov, ChrisGreen@jabber.dsd.lbl.gov;
chissgreen (AIM, Yahoo); chissg@hotmail.com (MSNM);
chris.h.green (Google Talk).

[mysqld]
datadir=/usr/local/osg-collector/vdt-app-data/mysql5/var
user=mysql
port=49152
socket=/usr/local/osg-collector/vdt-app-data/mysql5/var/mysql.sock

# Note that all the following options in green are those given in
MySQL's example
# configuration file for a "small" (~512MB) memory system.
key_buffer = 16M
max_allowed_packet = 1M
table_cache = 64
sort_buffer_size=512
net_buffer_length=8
read_buffer_size=256
read_rnd_buffer_size=512
myisam_sort_buffer_size = 8M

# Required for InnoDB
log-bin=mysql-bin
# Creates a binary log for transaction logging and rollback purposes.
autocommit = false
# Required for correct
# Gratia operation. Does not affect non-transactional engines (eg
# MyISAM). When set to false, assume all commands are part of a
# transaction that must be ended with a COMMIT or ROLLBACK.
# This behavior ay be altered on a per-connection basis if necessary.
log_bin_trust_function_creators=1
# Required for triggers and stored procedures with binary logging
# unless systematic measures are taken to declare what each function
# does that may not be reproducible. From the manual:
# By default, for a CREATE FUNCTION statement to be accepted,
# DETERMINISTIC or one of NO SQL and READS SQL DATA must be specified
# explicitly. Otherwise an error occurs:
#
# ERROR 1418 (HY000): This function has none of DETERMINISTIC, NO SQL,
# or READS SQL DATA in its declaration and binary logging is enabled
# (you *might* want to use the less safe log_bin_trust_function_creators
# variable)
#
# Assessment of the nature of a function is based on the "honesty" of
the
# creator: MySQL does not check that a function declared DETERMINISTIC
is
# free of statements that produce non-deterministic results.

innodb_buffer_pool_size = 16M
Memory use option appropriate for 512MB system
innodb_additional_mem_pool_size = 2M
Memory use option appropriate for 512MB system
innodb_log_file_size = 5M
# The size in bytes of each log file in a log
# group. Appropriate based on memory use options, above.
innodb_log_files_in_group = 2
# The number of log files in the log group. InnoDB writes to the files
in a
# circular fashion. The default (and recommended) is 2.
innodb_log_buffer_size = 8M
# The size in bytes of the buffer that InnoDB uses to write to the log
# files on disk. Sensible values range from 1MB to 8MB. The default is
1MB.
# A large log buffer allows large transactions to run without a need to
# write the log to disk before the transactions commit. Thus, if you
have
# big transactions, making the log buffer larger saves disk I/O.
innodb_lock_wait_timeout = 50
# The timeout in seconds an InnoDB transaction may wait for a lock
before
# being rolled back. InnoDB automatically detects transaction
deadlocks in its
# own lock table and rolls back the transaction. The default is 50
seconds.
# A lock wait for a MySQL table lock does not happen inside InnoDB,
and this
# timeout does not apply to that wait.
expire_logs_days = 7
# Number of days after which to expire binary
logs. The number is optional but a heavily loaded Gratia collector
will produce
a lot of log data which needs to be cleaned up periodically.
innodb_file_per_table
# If this variable is enabled, InnoDB creates each new table using its
# own .ibd file for storing data and indexes, rather than in the shared
# tablespace.
innodb_flush_log_at_trx_commit = 1
When this value is 1 (the default), the log buffer is written out to the
# log file at each transaction commit and the flush to disk operation is
# performed on the log file.
# The default value of this variable is 1, which is the value that is
# required for ACID compliance. This is definitely desired for the
case where we're trying to
# diagnose and/or fix DB corruption.

[client]
port=49152
socket=/usr/local/osg-collector/vdt-app-data/mysql5/var/mysql.sock
CC: John Weigand <weigand@fnal.gov>, Tim Cartwright <cat@cs.wisc.edu>, Philippe Canal <pcanal@fnal.gov>
Subject: [vdt-support #3524] More explanation of MySQL configuration option requests.
Date: Tue, 13 May 2008 14:37:29 -0500
To: Alain Roy <roy@cs.wisc.edu>, vdt-support@OPENSCIENCEGRID.ORG
From: Chris Green <greenc@fnal.gov>
Download (untitled) / with headers
text/plain 1.3k
Alain Roy wrote:
> We're going to release VDT 1.10.1 momentarily, this afternoon. So
> we're going to ship with what we have.
>
> My understanding is that only one critical for us to set during
> installation is "innodb_file_per_table", because it affects the
> construction of the database, and the rest can be added later by the
> system administrator. Is that correct? So although it's suboptimal, we
> have a working solution for our release because these changes can be
> documented.
True up to a point. "Added later by the administrator" is OK provided
they do at least one of them before trying to run the service.

autocommit = false

is especially important as otherwise rollback behavior on duplicates
(and other not-uncommon exception conditions) may cause DB inconsistencies.

log-bin, expire_log_days and log_bin_trust_function_creators aren't
heart-stopping as long as the existence of the first implies the
existence of the other two (the converse would be *bad*), but this may
also affect recovery ability from an improper shutdown of the DB.

The remaining options are, as you say, optional.

Thanks,
Chris.

PS Enjoy your vacation, keep your computer off and thanks for all your work.

--
Chris Green <greenc@fnal.gov>, FNAL CD/SCF/GRID; 'phone (630) 840-2167.
IRC: greenc@jabber.fnal.gov, ChrisGreen@jabber.dsd.lbl.gov;
chissgreen (AIM, Yahoo); chissg@hotmail.com (MSNM);
chris.h.green (Google Talk).
Download smime.p7s
application/x-pkcs7-signature 3.9k
Download (untitled) / with headers
text/plain 467b
We need to help Gratia get the right MySQL configuration. Gratia needs a
bunch of configuration. It might affect other MySQL databased. In
general that doesn't matter: Gratia will be installed standalone.
However, we run Gratia in our nightly tests. So how should we set up
MySQL? Should we do it in configure_mysql? configure_gratia? How do we
avoid problems with other components?

I'm giving the ticket to Tim, since I'll be on vacation for the next two
weeks.
Subject: [vdt-support #3524] need to discuss my.cnf changes for gratia
Date: Wed, 11 Jun 2008 15:55:07 -0500
To: vdt-support@OPENSCIENCEGRID.ORG
From: Tim Cartwright <cat@cs.wisc.edu>
Download (untitled) / with headers
text/plain 1.7k
[From John Weigand, 8 May 2008 10:07:33 CDT:]

Tim,

Let me know when you are available.

I need to discuss some changes to the my.cnf file for InnoDB tables in
Gratia and I would think for anyone using InnoDB.

You can view the my.cnf with the changes I am proposing here:
http://home.fnal.gov/~weigand/tmp/my.cnf.txt

The critical/main parameter for InnodB is the innodb_file_per_table

This tells MySql to create an individual tablespace for each file.

Without it, MySql will create a single tablespace usually called
ibdata1 which can make managing disk space difficult. It resides, in a
vdt installation, in VDT_LOCATION/vdt-app-data/mysql5/var. ALL
tables for ALL databases share this tablespace (InnoDB tables that is)

With 'innodb_file_per_table' enabled, you will see ibd files (which is
the data content of the table or tablespace) in the database
directory, i.e, VDT_LOCATION/vdt-app-data/mysql5/var/gratia/
JobUsageRecord.ibd.
There will be an ibd file for each table. This way it is at the
database level and if you need to put individual databases on
separate file systems, it can be done more easily. You cannot do it
in the single tablespace mode.

I am assuming that VDT's MySql is configured so that any new table is
created as InnoDB by default unless specifically specified on the
CREATE. I would suggest that these be the default my.cnf parameters
for all VDT MySql implementations.

Undoing a single tablespace implementation is basically a nightmare.
You have to dump the database, drop the tables, then reload. There
are a couple other things you have to do which we will find out as we
have several test databases that are in this single tablespace state
and causing us disk resource problems periodically.

John Weigand
Subject: [vdt-support #3524] SVN commit, rev 7880
To: vdt-support@cs.wisc.edu
From: cat@cs.wisc.edu
Download (untitled) / with headers
text/plain 303b
Commit comment:
Changed my.cnf to !include a separate options file for MySQL 5, so that we have
a place to put local config that will survive updates.


Changed files:
U vdt/branches/vdt-1.10.1/Configure-MySQL/vdt/setup/configure_mysql

To generate a diff:
svn diff -c 7880 file:///p/vdt/workspace/svn
Subject: [vdt-support #3524] SVN commit, rev 7881
To: vdt-support@cs.wisc.edu
From: cat@cs.wisc.edu
Download (untitled) / with headers
text/plain 432b
Commit comment:
Added code to make sure that a bunch of MySQL options are set in the new extra
options file. These options are required for the proper functioning of Gratia.
In theory, they shouldn't harm other MySQL 5 users, but the expectation is that
Gratia will run alone.


Changed files:
U vdt/branches/vdt-1.10.1/Configure-Gratia/vdt/setup/configure_gratia

To generate a diff:
svn diff -c 7881 file:///p/vdt/workspace/svn
Subject: [vdt-support #3524] SVN commit, rev 7889
To: vdt-support@cs.wisc.edu
From: cat@cs.wisc.edu
Download (untitled) / with headers
text/plain 241b
Commit comment:
Fixed bug in last commit: May need to create dir for extra options file.


Changed files:
U vdt/branches/vdt-1.10.1/Configure-MySQL/vdt/setup/configure_mysql

To generate a diff:
svn diff -c 7889 file:///p/vdt/workspace/svn
Subject: [vdt-support #3524] SVN commit, rev 7890
To: vdt-support@cs.wisc.edu
From: cat@cs.wisc.edu
Download (untitled) / with headers
text/plain 232b
Commit comment:
Bug fix to last commit: Corrected the values for two options.


Changed files:
U vdt/branches/vdt-1.10.1/Configure-Gratia/vdt/setup/configure_gratia

To generate a diff:
svn diff -c 7890 file:///p/vdt/workspace/svn
Subject: [vdt-support #3524] SVN commit, rev 7891
To: vdt-support@cs.wisc.edu
From: cat@cs.wisc.edu
Download (untitled) / with headers
text/plain 232b
Commit comment:
Another bug fix: autocommit cannot be set in an options file.


Changed files:
U vdt/branches/vdt-1.10.1/Configure-Gratia/vdt/setup/configure_gratia

To generate a diff:
svn diff -c 7891 file:///p/vdt/workspace/svn
Download (untitled) / with headers
text/plain 178b
Hi Chris,
These changes were released today in VDT 1.10.1e. Tim is out of the
office until Monday, so I will leave this ticket open in case he has any
final notes.

Thanks,
Scot
Finished a while ago. We assume it works…