dba tales from the front: from oracle to mysql ben krug dba, adapt technologies ben@adapt.com oscon...
Post on 24-Dec-2015
219 Views
Preview:
TRANSCRIPT
DBA Tales from the Front: from Oracle to
MySQL Ben KrugDBA, Adapt Technologies
ben@adapt.com
OSCON July 2007
Who I am:- DBA at Adapt Technologies
- database experience (chronologically): SAS, Mumps (!), Sybase, *Oracle*, DB2, mSQL,(PostgreSQL), now MySQL
- As a DBA, helped build an Oracle application that won a Smithsonian Award for Excellence in Computing
- Trivia: was once in an ad for Oracle, for the same system
What I’ll talk about:- what happened to me? (from Oracle to
MySQL)
- Oracle gestalt vs MySQL gestalt
- gotchas (battle wounds - maybe you can learn from our mistakes)
Slides are just an outline- handouts have more details
- for soft copies, email ben@adapt.com
DBA at Adapt – from Oracle to MySQL- Accepted position looking for RAC mastery...
got “Ask Tom's” book, Tales from the Oak Table, CBO book by Jonathan Lewis.
- Read in Tales from the Oak Table how when systems get heavily instrumented, it’s great, but it shows maturity, and is a sign newer systems are coming around the corner... few days later – find out my company is dropping Oracle for an open source database.
Oracle to MySQL: from no eyebrows to eyebrows…
Q: Are the differences in their websites symptomatic?- Oracle website (in my experience) was alway
slow, confusing, overblown
- MySQL website relatively simple, quick, and easy
What’s in a word?- Terminology is different
- (eg, schema vs tablespace vs database)
- (cheat sheet in handouts)
Differences in getting the scoop:
- Wading through Oracle PR gobbledy-gook vs having to research each item to find out about its existence or features.
- (eg storage engines, to see what they can actually do)
Differences in what they are- different products - be-all end-all vs a database
- oracle seemed more complicated - RAC, interconnects, fusion, etc etc - always new pieces and teasers and mystifying PR
- MySQL appeared more simple - a database. less confusing PR but also less documentation. (OTOH, user comments in docs.)
- oracle - which features do you buy - DB, which components, other products (Oracle Identity, etc etc)
- MySQL - buy (or don’t buy!) the DB
Different Philosophies?- Open source vs closed
- Who are they serving
- What are they trying to achieve
- Etc…
Different communities- Open source community vs proprietary source
community
- Knowledge of inner-workings of DB
- Mood of excitement with MySQL
- Who are the customers? (web 2.0!)
- Etc…
Different support experiences- Oracle - hated it
- log a tar, if it's not severity 1, good luck getting competent help if you ever hear back
- once had to make threats to get help with a mission-critical sev 1 (Oracle v7, to be fair)
- MySQL - love it!
- have always had timely help, almost always very knowledgeable, helpful, and interested
- don't need to try to get past level 1 support
Different scaling strategies- “scaling out” vs “scaling up”
OK, so go get it! - went to mysqlab.com and downloaded community
edition rpm's and installed them.
- build from source if you're hardcore
Get your developer / DBA tools- not like Oracle 10g with its instrumentation
(but can set up advisors, if you pay)
- MySQL GUI tools - MySQL Query Browser, MySQL Administrator, etc
Our first GOTCHA – storage engines- choose a storage engine! Eg…
- MyISAM - default, good performance, no FKs no ACID transactions
- NDB (for clustering) - in-memory only on 5.0
- InnoDB - FKs and ACID-compliant transactions (InnoBase owned by Oracle now)
- Falcon - coming...
- etc
Scaling strategies (scaling out)- replication configurations - master/slave
- if you're going to use sharding, beware issues for auto_increments, FKs, global views (failures if a host fails), etc
Set up your backups- mysqldump (exports)
- no hot backups for InnoDB? – linux can use LVM
- can also use mysqldumps and then binary logs to roll forward
- (but beware statement-based vs row-based logging, especially if you use auto-increments)
Set up your permissions- No roles
- can be based on where someone is coming from (what host or subnet)
- networking issues? IP-based vs name-based authentication
Build your DB! Issues…- InnoDB tables are clustered by PK, other keys
point to PK values
- beware that FKs in InnoDB can cause locking issues (lock wait timeouts)
Let the users in- users' connection settings
- @@autocomit - on by default
- can use init_connect settings to change
- beware - superusers bypass this!
Our next GOTCHA- collations
- default is latin1_swedish_ci
- 'a'='A'
- we use utf8, utf8_bin
- 'a'<>'A'
GOTCHA 3- autocommit=1 by default
- wanted autocommit turned off for most code, but on for one user
GOTCHA 3- autocommit=1 by default
- wanted autocommit turned off for most code, but on for one user
- 3a: init_connect and auto_commit, and that superusers bypass init_connect (which can be good)
GOTCHA 3- autocommit=1 by default
- wanted autocommit turned off for most code, but on for one user
- 3a: init_connect and auto_commit, and that superusers bypass it
- 3b: security information for users is spread between information_schema and mysql databases. ‘super’ is in mysql.user, not in information_schema tables. (In case you get bitten by 3a.)
Our next GOTCHA- SQL_MODEs -
- Inserting inserting bad data by default, rather than giving errors
- How 0’s can be used for null dates
GOTCHA- error messages that are not informative or are
misleading
- eg, errors involving foreign keys, indexes, and altering tables – you’d never guess the problem from the errors:
- MySQL Error Number 1005Can’t create table ‘.\mydb\#sql-328_45.frm’ (errno: 150)
GOTCHA- Locks are different! InnoDB locks... deal with
it:
- Writers blocking readers, readers blocking writers
- (row-level, not like Oracle block-level)
- Issues with foreign keys
- isolation levels
GOTCHA- using "force index" in a select doesn't really
"force" the use of the index
- InnoDB optimizes using a set number of "random dives" into a table to estimate statistics, and can still decide not to use a “forced” index
- (not like histograms or choosing how many rows to sample for statistics in Oracle)
Care for your database- GOTCHA: optimizing for an InnoDB table
prevents updates
- "large" table can take a long time
- one multi-Gig table took hours to optimize, but then query times were cut in half
Performance…- performance can suffer over time for inserts and
updates in large tables
- use optimize if possible (in spite of the GOTCHA)
- "insert on duplicate key update" (like Oracle's "merge")
So why do I love MySQL?- you can read the code, so people know how it
works (including support staff)
- (I can understand it - it's not a black box)
- enjoy the community (including Marten Mickos vs Larry Ellison)
- love the support
- it's a database - not middleware, Application server, etc. I like databases; that’s why I became a DBA.
And where do you go for help?- Buy support! It’s worth it – cheap and very useful.
- Read the docs, the blogs, watch planetmysql.com.
- Do a lot of googling
- Books I recommend: Pro MySQL by Jay Pipes (Apress) is like an “Ask Tom” type book. Sasha Pachev’s Understanding MySQL internals (O’Reilly) is a nice introduction to reading the code (if you want to)
- (With Oracle, you have to work to read the tomes – the docs and the few good books. With MySQL, you have to work to find what you’re going to read.)
top related