Author Topic: MySQL Admin.dat replacement  (Read 8683 times)

Paradox

  • Posts: 2612
  • Turrets: +253/-250
    • Paradox Designs
MySQL Admin.dat replacement
« on: May 31, 2009, 10:47:00 pm »
For a long time, I have been thinking about replacing the admin.dat with a MySQL database.
There are a number of reasons for this:
  • Easier to manage
  • More organized
  • Easier to integrate with other services

It would be easier to manage because there are already a number of external tools for dealing with MySQL, such as MySQL Administrator or phpMyAdmin

It would be more organized, because each separate part of admin.dat could be put into its own table. Eg admins, bans, commands, levels. All these would be in one schema.
In each, everything would be in row-column format, as this is basically how MySQL works.

Finally, it would be easier to integrate with other services, such as a ban viewer website or admin list.

We have thought of a few security things already, such as salting the GUIDs so they cannot be stolen, as well as other ideas.

Full discussion thread here:
http://forums.sstcentral.com/index.php?showtopic=4728

The patch is there, albeit hard to find. I hope slacker will post it as an attachment soon. In the mean time, its on fsm, and in a branch of fsm
------
If you are just going to say “This is stupid” or any derivative of such, move on, this is not for you. This includes “why use MySQL”
If you are looking to provide useful criticism, such as “seems you overlooked blah” or “i found a bug”, feel free!

∧OMG ENTROPY∧

MitSugna

  • Guest
Re: MySQL Admin.dat replacement
« Reply #1 on: May 31, 2009, 11:39:14 pm »
Good job.
I suggest you to use non-blocking queries if you are not already implemented this. Otherwise it pretty pointless. If it is blocking even if mysql runs on the same server there will be delays when querying the database.
Also postgresql is a good alternative for mysql. AFAIK postgresql is better at non-blocking queries. But if you already have mysql no need for extra trouble.

Since I was lazy I just separated the admin.dat into 4 parts without using a database. (code is in my previous post)

SlackerLinux

  • Spam Killer
  • *
  • Posts: 555
  • Turrets: +41/-62
Re: MySQL Admin.dat replacement
« Reply #2 on: May 31, 2009, 11:56:27 pm »
Good job.
I suggest you to use non-blocking queries if you are not already implemented this. Otherwise it pretty pointless. If it is blocking even if mysql runs on the same server there will be delays when querying the database.
Also postgresql is a good alternative for mysql. AFAIK postgresql is better at non-blocking queries. But if you already have mysql no need for extra trouble.

Since I was lazy I just separated the admin.dat into 4 parts without using a database. (code is in my previous post)


ill stress this is a WIP though since it hasn't really been tested and i know only basic mysql c api but it connects to the database and runs stuff and theres commands to get data back etc.

prostgresql would be an ok option maybe it could be possible to do both api and have it selectable or maybe a compile option but that can wait till later.
Slackware64 13.1
SlackersQVM/

Paradox

  • Posts: 2612
  • Turrets: +253/-250
    • Paradox Designs
Re: MySQL Admin.dat replacement
« Reply #3 on: June 01, 2009, 04:13:19 am »
If people wanted to use Postgre, i guess they could.

But the Reddit devs expressed pains about using Postgre, said they wished they used MySQL.

∧OMG ENTROPY∧

Archangel

  • Guest
Re: MySQL Admin.dat replacement
« Reply #4 on: June 01, 2009, 04:47:23 am »
AFAIK postgresql is better at non-blocking queries.

use innodb tables then, not myisam. innodb supports per-row locking, not table-locking like myisam does.

whitebear

  • Posts: 659
  • Turrets: +35/-20
Re: MySQL Admin.dat replacement
« Reply #5 on: June 14, 2009, 09:41:53 am »
So is it complete and is there official documentation? I am interested in using this. Right now I don't fancy reading a forum thread of few pages to find out.

SlackerLinux

  • Spam Killer
  • *
  • Posts: 555
  • Turrets: +41/-62
Re: MySQL Admin.dat replacement
« Reply #6 on: June 14, 2009, 10:35:58 am »
semi done not documented but if you know howto code you can kinda figure out what each function does what.
ive converted everything now i just need to clean it up and see how much slower it is. im busy atm so don't expect changes soon but they will come. only mysql backend completed but im learning pgsql too so we might get that too.

there's no guarantee that this wont slow down servers. just remember WIP and could be buggy at times :p
current tremded code can be found in a branch for fsm-trem. when i get time ill bring all the code i have done for qvm into 1 patch.
Slackware64 13.1
SlackersQVM/

Archangel

  • Guest
Re: MySQL Admin.dat replacement
« Reply #7 on: June 14, 2009, 11:03:25 am »
iluqvm has support for this. i'm attempting to get some sort of non-blocking queries in place. my current method (a simple usage of pthreads) works, but there's problems (as i am not quite familiar with the tremulous codebase, and really c in general)

SlackerLinux

  • Spam Killer
  • *
  • Posts: 555
  • Turrets: +41/-62
Re: MySQL Admin.dat replacement
« Reply #8 on: June 14, 2009, 12:26:08 pm »
iluqvm has support for this. i'm attempting to get some sort of non-blocking queries in place. my current method (a simple usage of pthreads) works, but there's problems (as i am not quite familiar with the tremulous codebase, and really c in general)

if i ran into speed issues testing that's what i was thinking of doing threading that part
Slackware64 13.1
SlackersQVM/

Archangel

  • Guest
Re: MySQL Admin.dat replacement
« Reply #9 on: June 14, 2009, 08:47:32 pm »
i did that, and now the i randomly lose connection to the mysql server (MySQL server has gone away). I also get random queries sometimes (i have query code to do INSERTs in the client connect routine) like '7' or the 'xxxx has entered the game' message. therefore I think there's something a bit wonky with just using plain pthreads in the tremded.