reviving a somewhat older windows server, have some questions
 

Hey all, I was running a private server for just a few select friends a year or so ago..interest waned and I shelved it for a while. Didn't delete anything, or move anything..but the server was running on my main machine, which I kept using and updating.

I decided I wanted to revive my server and play a bit again, but for whatever reason, the loginserver kept crashing within seconds of launching. I looked at version numbers and decided there were enough changes that rather than try to fix the problem, a full rebuild would be easier, so I went through the guide (again), compiled everything successfully, and got to the part where I set up the database. I know I could drop system and import the new one..but before I do that (yes I backed up as well), I wanted to just generally ask about how drastic the changes have been since roughly rev1900 to rev2500ish. Is it going to be relatively viable to move forward or should I just back up my account/character data and re-source the entire thing from scratch, then restore what I want? Also, should I be worried about client compatibility? I was using SoD prior.

At this point if it were me, I would backup everything. Install everything from scratch and make sure everything works with a new character, maybe even play a bit to make positive there are no issues. Then I would just create some SQL statements to move the accounts, characters and such over.

Thanks, I think that's probably what I'm going to do. I've already backed up the database, and then I've gone further and selectively dumped individual tables (or in some cases, just specific data sets from those tables) to sql to restore. Was hoping not to have to do that, but it looks like the changes might be too much to easily just keep jumping upwards by upgrades/revision imports.

I am going to try to just drop the system and keep accounts intact first..unless there have been major changes to those tables as well?

Well the best thing to do is try it. It will tell you pretty quick if there are problems, monitor those error log files.

Well, as it turns out, apparently the login server is still crashing when the world server finishes loading zones and connects to it.

Problem signature:
Problem Event Name: APPCRASH
Application Name: EQEmuLoginServer.exe
Application Version: 0.0.0.0
Application Timestamp: 4d03c97f
Fault Module Name: LIBMYSQL.dll
Fault Module Version: 0.0.0.0
Fault Module Timestamp: 4f8bcacf
Exception Code: c0000005
Exception Offset: 00009b3a
OS Version: 6.1.7601.2.1.0.256.1
Locale ID: 1033
Additional Information 1: 0a9e
Additional Information 2: 0a9e372d3b4ad19135b953a78882e789
Additional Information 3: 0a9e
Additional Information 4: 0a9e372d3b4ad19135b953a78882e789

I didn't rip out all the installs and reinstall them from scratch, so I am backing up the current db, ripping everything out from the roots, and going 100% from scratch this time around, then I'll just source my backup db which contains the updates.

Welp, got stopped in my tracks. uninstalled (and even manual purged) mysql, in prep to reinstall the correct version..
Installed correct version, got to configure it, and it can't start the service. Can't start it manually either. I've even gone through it a couple times uninstalling, purging the data folders manually, purging the service registry keys manually, etc...still can't get it. I think this machine is hosed as far as mysql goes, unless I wipe and reinstall windows. I'm going to move the whole thing to a virtual server for now until I build my dedicated box for it I think. Unless anyone knows how to get around that service issue...

I do both of my servers as VM's, there are so many advantages to it.

Honestly I'm hopefully on the verge of a new job where what i want will be possible...so if that happens I intend to actually build 3-4 physical machines that actually support vSphere, and then run VM servers for various purposes, and actually have the zoneservers spread across the physical machines as well. I guess this might end up being my solution for now and then it'll just be portable to the vSphere machines when they're built.

Apparently I'm stopped in my tracks yet again. Brand new server 2008r2 standard VM, and mysql again refuses to start as a service. I'm at my wits end on this one, and I've done this successfully all before. Anyone know how to deal with this mysql error log?

131116 17:23:15 [Note] Plugin 'FEDERATED' is disabled.
131116 17:23:15 InnoDB: Initializing buffer pool, size = 2.0G
131116 17:23:15 InnoDB: Error: cannot allocate 2147500032 bytes of
InnoDB: memory with malloc! Total allocated memory
InnoDB: by InnoDB 30993228 bytes. Operating system errno: 8
InnoDB: Check if you should increase the swap file or
InnoDB: ulimits of your operating system.
InnoDB: On FreeBSD check you have compiled the OS with
InnoDB: a big enough maximum process size.
InnoDB: Note that in most 32-bit computers the process
InnoDB: memory space is limited to 2 GB or 4 GB.
InnoDB: We keep retrying the allocation for 60 seconds...
131116 17:24:15InnoDB: Fatal error: cannot allocate the memory for the buffer pool
131116 17:24:15 [ERROR] Plugin 'InnoDB' init function returned error.
131116 17:24:15 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.
131116 17:24:15 [ERROR] Unknown/unsupported table type: INNODB
131116 17:24:15 [ERROR] Aborting

131116 17:24:15 [Note] C:\Program Files (x86)\MySQL\MySQL Server 5.1\bin\mysqld: Shutdown complete

Ok, after making my 2nd vm and testing it yet again on a fresh install of win7...I'm forced to conclude that the problem is with mysql-5.1.72
I've found a copy of the 5.1.68 installer (since it isn't available on oracle's official site), and am trying that next.

They have most all of there old GA releases available on the MySQL site so you should have no issues finding old versions.

weird, because I went to the old GA archives and it only offered me .72
either way I've got a fresh VM now, with a snapshot AT its immediate post-install state so I don't have to uninstall, I'll just revert to snapshot on failure...but I'm going to figure out why mysql hates me.

Snapshots rock.

wow...I clearly have something wrong. Fresh vm, fresh 5.1.68, still have the "cannot start service" error on install. No clue at this point, and on the verge of giving up.

I am of limited help since my server is on Debian, but what O.S. is this and is it a fresh install? Where did you snapshot? Before or after the MySQL install?

Incidentally, just to give specs, I'm currently running vmware workstation 10, windows 7 ultimate x64 with sp1, allocating 8gb of ram to the vm, with 2x dualcore cpus to the vm (I have plenty of hardware on the host machine). 60gb virtual hard drive. I am not patching in any way before the install of mysql. This is as fresh as it gets off the win7 install disc (an ISO I got through my MSDN subscription).

The snapshot is immediately after win7 itself finishes its install. There isn't a single bit of post-install modification on it.

x32 or x64?

OS is x64, I need that for the amount of RAM I'm allocating. I'm using the 32bit installer per the instructions in the server guide.

I see no reason to use the x32 bit of MySQL unless I am missing something. Revert your snapshot, install the x64 and try again. Also just for giggles disable the Windows Firewall.

I'll give those a shot. I ONLY used the 32bit versions because the guide said to, and I've successfully used the guide to set up the server before (and had quite a bit of enjoyable playtime out of it). I do prefer using 64 bit when I can unless there's a specific reason not to.

Hah. 64bit worked first try. I guess the 32 bit installer truly hates 64bit windows. I think I will keep the server as a vm and proceed with the rest then.

speaking of ram, I wonder how much ram would be necessary cumulatively to run every single zone as a static, and only have dynamics for instanced content...

My personal findings, and this is just me....I had problems with static zones. Memory wise they did not tax my server at all, it was an issue with the day/night cycles and maybe a few old peq scripts that need TLC, the zone logs got huge and that told me the server was constantly having to write to these log files. Other zones would randomly shutdown and I think it was script problems, I run vanilla PEQ. I run a pseudo dynamic / static zone thing where the zones stay open for maybe an hour, then close if they are vacant.

hmm..well what I was running was statics that contained any valid rare/named/group/raid targets that my friends and I were actively interested in. If it were too high or too low, I just kept 'em dynamic. Then again I'm also planning on those vsphere boxes and spreading the zoneservers out across them.

I may go back to statics but this time I will start with classics and run them for a while and weed out the bad zones, then go from there.

Gah I could kick myself right now. In my frustrations last night to reinstall mysql I backed up the peq database, but I was still using the older system that used a separate peqlogindb database and forgot to back up my accounts. I still have all the character data, but now I gotta rebuild the accounts in the correct order so they attach to the character data properly >.<

Unless you have a ton, it should not be a major endeavor.

*sigh* any ideas? Yes I put the login tables directly into peq instead of peqlogindb like they used to be.

I'm also getting a TON of errors in every single zone launch and on other files:

queryserv:
Various zone errors, all the same it seems:

Try 127.0.0.1 rather than localhost.

lerxst thanks, that got me a bit further. Still having issues but I think that's from losing the login database and having to rebuild it by hand, slowly.

ok new stumbling block. I redid my eqemu_config.xml and login.ini because my old versions were out of date and missing stuff for queryserv and what not. After fiddling with IPs and account names, I'm now to this in the login server window. Everything else seems to be functional at this point. ALL of my internal IPs are now 127.0.0.1, because using the computer's own address of 192.168.1.5 would get rejected for some strange reason.

EDIT: nevermind. Solved it. I had the password for the server login table encrypted SHA like accounts are, put it into plaintext and it worked fine. :)

Ok, I think this might be the last step to getting the server reanimated from the grave. I had forgotten that the old login db was a separate db, so in my fury to delete/reinstall mysql a few times a couple days ago, I deleted the whole directory after dumping peq, but forgetting about peqlogindb. I didn't empty recycle bin, recovered the raw data files, but don't have the server instance or anything in registry left. What's the easiest way to attach those raw data files to a server to extract whats in them? If I can get access, I can just migrate the data easy enough.

Edit: don't have the account data file..only had the adminregistration table and serverlisttype >.< by hand it is.

Sounds like you have really been thrown some bad luck here.
Hope you figure it out, I'll watch this thread for a few days in case you have more issues that I might be able to assist with.

Thanks Wolf, I think I actually managed to figure out most of it. I had to rebuild the login table by hand, which ended up making the tblLoginAccounts ID field out of sync with Accounts.lsaccount_id, so a simple query to rewrite that id to match the login table data made the rest sync up. Successfully logged in with multiple accounts now, characters, tested fights...I did briefly encounter a "invulnerable to melee" issue, but haven't since a reboot.

I do believe that unless unforeseen issues come up, the server is ready for play again, and luckily, all character and valuable player data is intact. :)

Thats good to hear. Also you made sure, double checked & triple checked, to run all the SQL that match up with the version of source you are updating to?

Yep, did that successfully. I'm still being very alert to other possible bugs popping up as a result of this transfer, but I'd rather have the headaches than lose all the progress the server has on its 50 or so characters, most of whom are max level (but horribly under-geared). :)