Forums » Suggestions
Yea your all a bunch of babies.
[heavy edit]
beloach at the very least they could save everyones 'simple numbers'; kills, deaths, faction ratings, skill levels, etc. i bet u 1 million credits this would require no table locking and no complicated queries. its probably 20k of data total for all users; a straight dump to a simple file. 50 lines of python (1 line of perl?).
in emergencies people who truly lost a lot of stuff could /msg a guide or DBA to repair their character 'by hand' using simple scripts/forms/whatever.
beloach at the very least they could save everyones 'simple numbers'; kills, deaths, faction ratings, skill levels, etc. i bet u 1 million credits this would require no table locking and no complicated queries. its probably 20k of data total for all users; a straight dump to a simple file. 50 lines of python (1 line of perl?).
in emergencies people who truly lost a lot of stuff could /msg a guide or DBA to repair their character 'by hand' using simple scripts/forms/whatever.
Making any database backup still requires locking the tables, whether it be a real mysql dump or a magic mysql->sqlite dump...
That's precisely what I was doing; I was writing such a script/form/whatever. It wasn't dropping/adding entire tables, it was just dumping a few rows out of a backup DB using the -w option to mysqldump (to be precise, it loads the entire dump into a temporary database and then dumps out the parts it needs.. the reason being that the dumps are composed of compound insert statements). That should have just given me some insert statements but it also gave me the table drop/create statements. So yeah, the script just filters out everything but the INSERT INTO statements from whichever selected backup file.
Good [morning|afternoon|evening]!
Why not use some decent RDBMS, which supports PITR?
With all due respect to mySQL, it is just multiuser stable and extremely powerful Access(God forgive me mentioning this M$ spawn, unduly registered as database).
I don't mean using something like Oracle or DB/2, it's a little overkill. Although PostgreSQL is free (BSD license), and features online and archived redo logs (WAL - Write Ahead Log, by their terminology), which enable Point In Time Recovery.
You could backup regularly once per day. If something unfortunate happens, you just restore old backup and then roll forward until point in time you specify. Which could be LAST transaction or instant BEFORE someone deleted all users...
In case you need pretty experienced DBA advice, I would be glad to lend you my assistance. (You have my email address)
grayswander
Oracle DBA and developer
Why not use some decent RDBMS, which supports PITR?
With all due respect to mySQL, it is just multiuser stable and extremely powerful Access(God forgive me mentioning this M$ spawn, unduly registered as database).
I don't mean using something like Oracle or DB/2, it's a little overkill. Although PostgreSQL is free (BSD license), and features online and archived redo logs (WAL - Write Ahead Log, by their terminology), which enable Point In Time Recovery.
You could backup regularly once per day. If something unfortunate happens, you just restore old backup and then roll forward until point in time you specify. Which could be LAST transaction or instant BEFORE someone deleted all users...
In case you need pretty experienced DBA advice, I would be glad to lend you my assistance. (You have my email address)
grayswander
Oracle DBA and developer
Hi, I'd just like to point out that this is the first time we've ever had to do a database rollback. Once in three years or so isn't so bad, is it?
Gray: good point on the database migration, we may take a look at it sometime soon, but it's kind of a hassle to migrate. MySQL may not be ideal, but it's pretty stable and has worked well (sans a few user-error issues like this one). Anyway, we're looking at upgrading the database server in the next couple of months, we'll consider doing a migration at the same time.
Gray: good point on the database migration, we may take a look at it sometime soon, but it's kind of a hassle to migrate. MySQL may not be ideal, but it's pretty stable and has worked well (sans a few user-error issues like this one). Anyway, we're looking at upgrading the database server in the next couple of months, we'll consider doing a migration at the same time.
Gray: I forgive you
yeah but im just saying that 3 years from now, there might be 10,000 players.
10,000 * ($10 a month)/4 = $25,000 mistake.