The Cache: Technology Expert's Forum
 
*
Welcome, Guest. Please login or register. September 16, 2019, 05:10:18 PM

Login with username, password and session length


Pages: [1] 2
  Print  
Author Topic: How to deploy from Dev mysql to Live mysql?  (Read 5851 times)
nutballs
Administrator
Lifer
*****
Offline Offline

Posts: 5627


Back in my day we had 9 planets


View Profile
« on: April 10, 2009, 08:12:06 PM »

think I got the website deployment method figured out, but...

what about mysql?

how do you deploy changes that you make to mysql on a dev server live?
manually?
is there anything that can simplify the process?
Frankly Im not sure I would trust anything anyway, other than manual. but curious if there are options.

losing a website is easy to fix, you just grab your backup and your done.
losing a database, not usually so easy to fix.
Logged

I could eat a bowl of Alphabet Soup and shit a better argument than that.
perkiset
Olde World Hacker
Administrator
Lifer
*****
Offline Offline

Posts: 10096



View Profile
« Reply #1 on: April 12, 2009, 10:14:25 AM »

Replication. It's the shiz.

http://dev.mysql.com/doc/refman/5.1/en/replication.html

I use it for my near-line failover as well as backups. Tasking for dev->production would be trivial. You can even do master<->master, although it's a little more tricky and I find that it's a bit less stable.
Logged

It is now believed, that after having lived in one compound with 3 wives and never leaving the house for 5 years, Bin Laden called the U.S. Navy Seals himself.
nutballs
Administrator
Lifer
*****
Offline Offline

Posts: 5627


Back in my day we had 9 planets


View Profile
« Reply #2 on: April 12, 2009, 01:53:29 PM »

replication though is real time though isnt it?

scenario is this.
adding a new column to dev.
populating with data to test it.
dont want that data going live.
Logged

I could eat a bowl of Alphabet Soup and shit a better argument than that.
vsloathe
vim ftw!
Global Moderator
Lifer
*****
Offline Offline

Posts: 1669



View Profile
« Reply #3 on: April 13, 2009, 11:48:18 AM »

Even though we have a fairly automated versioning system where I work, I think they still rely on manual pushes of database "stuff".

So, that might tell you how plausible this would be.

Then again, I can't really think of any time that you would need to make changes to your database...

If you're just importing data...well then it's just a data import. If you're making changes to your DB structure due to code changes...you're doing it wrong. Databases aren't something you modify on a regular basis...
Logged

hai
nutballs
Administrator
Lifer
*****
Offline Offline

Posts: 5627


Back in my day we had 9 planets


View Profile
« Reply #4 on: April 13, 2009, 11:56:18 AM »

you dont have my clients apparently... LOL
Logged

I could eat a bowl of Alphabet Soup and shit a better argument than that.
perkiset
Olde World Hacker
Administrator
Lifer
*****
Offline Offline

Posts: 10096



View Profile
« Reply #5 on: April 13, 2009, 07:36:58 PM »

Hey Nuts - just got back in. F'ing WHUPPED but your assistance really, really helped. Share more when I have a brain about me later this week.

Replication is on/off on command. You can START SLAVE and STOP SLAVE at will. Changes to the database will be kept in a .BIN file on the master until it has disgorged changes to the slave. If you go this direction you'll want to also flush the BINs out periodically, as they tend to get really big.

Bear in mind also, that everything you do to the master database will be moved to the slave when you turn it on, so change left, change right, change back left will all get moved in exact sequence to the slave. It may not be the best solution, but it is worth a look.
Logged

It is now believed, that after having lived in one compound with 3 wives and never leaving the house for 5 years, Bin Laden called the U.S. Navy Seals himself.
vsloathe
vim ftw!
Global Moderator
Lifer
*****
Offline Offline

Posts: 1669



View Profile
« Reply #6 on: April 14, 2009, 08:52:42 AM »

you dont have my clients apparently... LOL

Apparently not.

But I've had scope changes, complete reversals of direction, and every other conceivable client-related last-minute FUBAR imaginable, I would think. Not once have I had to restructure a database as a result. A database is like a building's foundation - if you need to modify the structure, everything else needs to come down first and be completely rebuilt. Literally. Well, that's my design paradigm anyway, I don't claim that it's the best but I've been happy with it.
Logged

hai
nutballs
Administrator
Lifer
*****
Offline Offline

Posts: 5627


Back in my day we had 9 planets


View Profile
« Reply #7 on: April 14, 2009, 09:02:52 AM »

i fully agree.
BUT...

One of my major sales points is that I am a fixer.
When other people fuck up the project so bad, that it is dead in the water, or going to miss a deadline, I fix it.
All of it.
So often, I am in "just get it done as fast as possible" mode. Which of course does not produce well thought out foundations.

But the most common example is a client wanting to store 1 more piece of data that was never stored before.
In a small, low scale database, I would have designed it to be relational, ie, userkey->tableofthings. However, when you are talking about millions of records, being pounded to shit non-stop (high availability, large dataset), all those joins add a bit of overhead.

But my main excuse is time. I never have it. It's always a panic phone call, "OMG OMGOMG we need to get 4 weeks of project work done by friday!!!!!!! HEEEEEEEEEEEEEEEEELP!" So, i just plow forward, often painting myself into corners, and having to build teleporters to get out of the mess.

The ironic thing is, that unintentionally i become entrenched, and I am the only person who can deal with the code. So they do the evil for me. LOL
Logged

I could eat a bowl of Alphabet Soup and shit a better argument than that.
perkiset
Olde World Hacker
Administrator
Lifer
*****
Offline Offline

Posts: 10096



View Profile
« Reply #8 on: April 14, 2009, 10:48:30 AM »

A database is like a building's foundation - if you need to modify the structure, everything else needs to come down first and be completely rebuilt. Literally. Well, that's my design paradigm anyway, I don't claim that it's the best but I've been happy with it.

Wow ... if I lived that way I'd be a complete mess.

IME, business requirements NEVER fully capture what the outside requirements of the DB will be. I create my DBs with the notion that there will probably be some wiggling through the life of the app(s). I write everything from the perspective that I cannot know how it will finally turn out - so when changes do come (the addition of a column and such) it has no impact to running systems.

All that said, I agree that it is the foundation and I shoot my best work at that part of the effort - and usually, changes/additions are pretty small. But they do occur. Just sayin'.
Logged

It is now believed, that after having lived in one compound with 3 wives and never leaving the house for 5 years, Bin Laden called the U.S. Navy Seals himself.
nutballs
Administrator
Lifer
*****
Offline Offline

Posts: 5627


Back in my day we had 9 planets


View Profile
« Reply #9 on: April 14, 2009, 12:11:23 PM »

What are these "business requirements" you speak of?
Are they like these mystical "specifications" I hear about?
 

Logged

I could eat a bowl of Alphabet Soup and shit a better argument than that.
perkiset
Olde World Hacker
Administrator
Lifer
*****
Offline Offline

Posts: 10096



View Profile
« Reply #10 on: April 14, 2009, 12:19:05 PM »

They are a mythical talisman of Techguy pain that is yet to be. They often speak in two or more tongues, always in cryptic nonsensical forms, and most often presented to the initiate from a short-sleeved white button down guy that says things like "This pseudomechanical 'leever' (lever pronounced with a long E) will profoundly affect our current operating paradigm."

Although theoretically a road map to salvation, they are more often a winding path to destruction, obscurity and never-ending gnashing of teeth. I believe you can find further references by looking up "Sisyphus."
Logged

It is now believed, that after having lived in one compound with 3 wives and never leaving the house for 5 years, Bin Laden called the U.S. Navy Seals himself.
nutballs
Administrator
Lifer
*****
Offline Offline

Posts: 5627


Back in my day we had 9 planets


View Profile
« Reply #11 on: April 14, 2009, 01:10:19 PM »

lol
Logged

I could eat a bowl of Alphabet Soup and shit a better argument than that.
vsloathe
vim ftw!
Global Moderator
Lifer
*****
Offline Offline

Posts: 1669



View Profile
« Reply #12 on: April 15, 2009, 07:22:46 AM »

A database is like a building's foundation - if you need to modify the structure, everything else needs to come down first and be completely rebuilt. Literally. Well, that's my design paradigm anyway, I don't claim that it's the best but I've been happy with it.

Wow ... if I lived that way I'd be a complete mess.

IME, business requirements NEVER fully capture what the outside requirements of the DB will be. I create my DBs with the notion that there will probably be some wiggling through the life of the app(s). I write everything from the perspective that I cannot know how it will finally turn out - so when changes do come (the addition of a column and such) it has no impact to running systems.

All that said, I agree that it is the foundation and I shoot my best work at that part of the effort - and usually, changes/additions are pretty small. But they do occur. Just sayin'.

Do you actually build a distinct middleware layer, though? I've had to write enterprise-grade apps where the low-level database *cannot* ever be changed. I've been on projects where that was one of the fundamental design principles. But I think we're talking about two different things. I frequently have to change the structure of databases that only hold data, the databases I'm talking about hold *everything*. Code, data, everything. They're normalized to the nines, and should anything ever have to change, it would be pretty disastrous. The top layer is very very dumb and has no idea what's going on down there, because even the databases that the middleware talks to are abstracted by accessor methods that allow you to do complex constraints. It's probably easier to exemplify than explain:

Code:
<?php
$cc 
= new contentClass();
$cc->addConstraint('contentType''=''story');
$cc->addConstraint('location''near''Buffalo');
$cc->addConstraint('price''<''500');
$contentObject =& $cc->select();

None of those fields has to even exist for me to check on it. I can add them on the fly simply by associating a specific characteristic to an entity, ex:

Code:
<?php
$cc 
= new contentClass();
$cc->selectEntityByID('1235');
$cc->setData('location''Chicago');
$cc->setData('randomData''whateverIwant');
« Last Edit: April 15, 2009, 07:29:25 AM by vsloathe » Logged

hai
vsloathe
vim ftw!
Global Moderator
Lifer
*****
Offline Offline

Posts: 1669



View Profile
« Reply #13 on: April 15, 2009, 07:28:37 AM »

Simple insert:

Code:
<?php
$cc 
= new contentClass();
$newContentObject $cc->createContentObject();
$newContentObject->setData('type''article');
$newContentObject->setData('content''lorem ipsum.....');
$cc->insertContentObject($newContentObject);
?>

Logged

hai
nutballs
Administrator
Lifer
*****
Offline Offline

Posts: 5627


Back in my day we had 9 planets


View Profile
« Reply #14 on: April 15, 2009, 08:58:50 AM »

oh of course in that environment, that makes sense. database can't be changed is a rule of the system.

That usually implies the database already exists though, and that they are already storing everything they "need".

an example however of where this all goes out the window is credit cards. When they added the CID/CVV/CVC to cards, that had to be stored somewhere, and it wasn't before. I am willing to bet that there were a lot of asinine conversations about how the "database can never be changed". maybe its shitty example. I dunno.

So how do you handle, something like, having customer records, which has a shitload of fields, and the powers that be, now decide they want a new piece of data stored "masturbationsperweek". add a new table with keys to the user record? what about when they want another column added a few weeks later? and then another?

I think we might be talking about two different situations. You are talking about a database that is out of your control i think? I am talking about a database 100% in my control, being directed by retarded suits as to what they need stored on a whim of the day. Its VERY frustrating to not be allowed to do things correctly, but then again, they pay silly money to me, and never ever have questioned an invoice, even when it was absurdly big.
Logged

I could eat a bowl of Alphabet Soup and shit a better argument than that.
Pages: [1] 2
  Print  
 
Jump to:  

Perkiset's Place Home   Best of The Cache   phpMyIDE: MySQL Stored Procedures, Functions & Triggers
Politics @ Perkiset's   Pinkhat's Perspective   
cache
mart
coder
programmers
ajax
php
javascript
Powered by MySQL Powered by PHP Powered by SMF 1.1.2 | SMF © 2006-2007, Simple Machines LLC
Seo4Smf v0.2 © Webmaster's Talks


Valid XHTML 1.0! Valid CSS!