<jgelb_near> it's R/O, I guess?
<jgelb_near> lets take a step back...
<jgelb_near> I'm setting up db access tools and docs for vhosting
<jgelb_near> and i'd like to abstract the connection info used by the end-users from our implementation
<henry> ack
<jgelb_near> so rather than have them use the IP address or the internal hostname, I was figuring that a more generic and portable DNS alias would be easier to do
<jgelb_near> so
<jgelb_near> with that in mind ...
<henry> ack agree
--> shadow (stwombly@cmg-629B3371.cncdnh.fios.verizon.net) has joined #sysadm
<jgelb_near> do we usually point people at the master or slave?
<henry> master.
<jgelb_near> ack
<jgelb_near> ok
<jgelb_near> so
<henry> one thing to keep in mind is also during migration off of oraplace - we will have 2 clusters running
<jgelb_near> making mysql4prod.pearsoncmg.com point at the master doesn't set a precendent that we haven't already done.
<henry> and both will prob be running v4 and v5 servers
<jgelb_near> ack
<jgelb_near> should I be thinking about a naming scheme that makes it easier to do that migration?
<henry> hmmm not sure how to avoid having 2 names and having people cchange them for migration
<henry> since migration will not be transparent
<jgelb_near> well...
<jgelb_near> could set up a name per app
<jgelb_near> as CNAME or A record to current master for now
<henry> you know that is what we are thinking of oding for oracle
<jgelb_near> ack
<henry> instaed of dbserver-050-vip - have it tpidb-1 or somerhintg
<jgelb_near> ack
<jgelb_near> or ... mysql.foo.bar.com
<jgelb_near> just one more dns entry for each vhost
<henry> for mysql on vhosts that works well.
<henry> and oracle on vhosts as well.
<p2v_wal> 1955-chassis-010 kvm is back
<henry> for non-vhosted applications will prob need to be something slightly diff
<jgelb_near> right
<jgelb_near> similar idea, different naming scheme
<henry> ack. prob not too diff but yea.
* p2v_wal heading out
<shadow> tks peter
--- p2v_wal is now known as p2v_bbl
<p2v_bbl> np
<jgelb_near> so
<jgelb_near> for vhosting use ...
<-- p2v_bbl has quit (Ping timeout)
<jgelb_near> mysql4prod.foo.bar.com, mysql4dev.foo.bar.com
<henry> don't see version info needed anymore
<jgelb_near> well
<jgelb_near> I can see how we can migrate someone from v4 cluster 1 to v4 cluster 2 with just a downtime notification and no user effort
<jgelb_near> but v4 to v5 would have to be an app driven thing because of potential feature differences
<jgelb_near> so the version name lets us provide both options and have the migration happen when the end user can test
<jgelb_near> and v6, etc...
<henry> hmm just wondering if a diff name is sufficient. thinking maybe migration woin't be just v4-> v5
<henry> but may be v5 innodb -> v5 isam
<jgelb_near> that's outside the scope of the hostname, though.
<jgelb_near> i.e. v5 mysql server can have tables/dbs that are innodb or isam or mysql or db4 or whatever
<henry> but may be diff vip as part of migration
<jgelb_near> on a per db basis
<henry> well I think the overall convention does not preclude additional names anyways
<jgelb_near> ack
<jgelb_near> if we wanted to field an innodb-only server, we can always an additional alias
<henry> ack
<henry> brb
<jgelb_near> generally speaking, though, I think that the mysql version # is the global constant that's most closely associated with a difference between one server/cluster and another
<henry> ack
<jgelb_near> and the rest is a per-db, per-app choise