Jump to content

osman84

Clients
  • Posts

    47
  • Joined

  • Last visited

 Content Type 

Downloads

Release Notes

IPS4 Guides

IPS4 Developer Documentation

Invision Community Blog

Development Blog

Deprecation Tracker

Providers Directory

Forums

Events

Store

Gallery

Everything posted by osman84

  1. Thanks for the feedback. I've personally done all 4 processes at some point in the past. #3 has been the most feasible for me, it's basically what you did except you can copy the files/code at your convenience, so the downtime is just for the DB move. #4 is of course the best experience for your users, but I'll admit it is quite a bit of work. Thanks for pointing out the TTL trick. I've tried it in the past, and you're right, it does help a lot. But I still had a few users (I'd say around 1%) who were somehow still accessing the old site up to at least 24 hours after the switch. I think it might be that there are some bad clients out there who don't enforce the TTL and cache up to the maximum? (but I'm no DNS expert)
  2. Hey guys, So I'm not an expert (in anything), but I've been running a few pretty active forums for almost 8 years now (most of these years were IP.Board!). I've had to endure several server moves. I wanted to write a brief outline of my experience, since moving an active forum to a new server isn't the easiest thing in the world. The dilemma with moving an active forum is that: a) because it's active, you don't want your many users to tolerate any downtime. b) because it's active, chances are your DB is huge and so this increases the time required to move over, and the potential downtime. Moving a forum entails a few things: 1) Getting the code up and running on your new server 2) Getting the database moved over to your new server 3) Pointing your users at the new server. I'll assume you're sticking with the same domain so this will be just a DNS flick. Solution #1: You could blindly do these three steps, but you'll be faced with a bunch of issues. The main one is that you will have two servers running off of different DB's, and there's no way to guarantee that the DNS change propagates at the same time for all your users. You'll have people posting and browsing the old forum, and people posting and browsing the new forum. Any changes to the "old" forum will disappear once everyone has propagated over to the new forum. Unacceptable. Downtime: None. Discrepancy: Yes. Solution #2: To prevent the discrepancy between having and old and new forums running, you could just turn your board "offline" during the propagation period. The procedure would be: a) turn the board offline on the old server b) move the code/DB over c) wait for propagation period d) turn the board online again on the new server. This will prevent your users from wondering where their posts went, but you have to remain offline for the DNS propagation period (which is on the order of hours, and reportedly can be even more). Again, unacceptable, because you don't want to be down for hours. Downtime: Several hours, but you can post a nice message. Discrepancy: None Solution #3: Point both servers at one DB (DB-copy). The procedure is: a) Setup/copy all code to the new server b) Turn your forum offline. c) Copy your DB over to the new forum d) Point both servers code to the DB on the new server e) Turn your forum online. f) Flip the DNS switch and wait for propagation. By pointing both servers at one database, you guarantee no discrepancy. That way, whether users are accessing the old or new server when DNS propagates, they will see the same things. You only need turn your forum off for the duration of DB copy, which you can probably pull-off in less than an hour, depending on the size of the DB. Downtime: Probably on the order of minutes, and you get to post a nice message. Discrepancy: None Solution #4: Point both servers at one DB (DB-replication). The procedure is: a) Setup/copy all code to the new server b) Setup master->slave replication between the old and new DB's c) Point both servers' code to the DB on the new server (which is the slave) d) Cancel the master/slave replication on both servers e) Flip the DNS switch and wait for propagation. Essentially, this is the same as solution #3 but instead of having to turn the board off, you rely on MySQL's replication functionality, which lets your new DB mirror your old one. The one issue is that replication requires a bit of technical know-how. There's a good guide here. Also, that you will have a bit of cross-server traffic (for the DB replication, and from the old server's code to the new server's DB during propagation). I just tried this on a site with several GB's worth of MySQL DB (forum, etc) with zero downtime as far as my users are concerned. A completely transparent move. Downtime: None Discrepancy: None The devil is always in the details, and I didn't go into any of the technical ones. There's some good guides around about how to carry-out any of these steps, and they'd probably do a better job than I can. I just wanted to point out that there is a process whereby you can move a large, active forum in a way that's transparent to your users.
  3. I'm getting this same issue. I've converted to UTF8, and in PhpMyAdmin I can read my strings fine with UTF-8 encoding, but my IPB 3.0.0 displays these strings as question marks. I tried putting: $INFO['sql_charset'] = 'utf8' But this gives me an error: Fatal error: Uncaught exception 'Exception' with message 'Could not initiate the registry, the settings cache is empty or missing' in /home/ismaily/public_html/testupgrade/admin/sources/base/ipsRegistry.php:1627 Stack trace: #0 /home/ismaily/public_html/testupgrade/admin/sources/base/ipsRegistry.php(498): ipsRegistry->setUpSettings() #1 /home/ismaily/public_html/testupgrade/admin/sources/base/ipsController.php(75): ipsRegistry::init() #2 /home/ismaily/public_html/testupgrade/admin/sources/base/ipsController.php(62): ipsController->init() #3 /home/ismaily/public_html/testupgrade/index.php(24): ipsController::run() #4 {main} thrown in /home/ismaily/public_html/testupgrade/admin/sources/base/ipsRegistry.php on line 1627
×
×
  • Create New...