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