7 days to upgrade Spacebattles

* jack is fictional

Jack looks at the available forum software available (due diligence) which include a native importer and which will incur the least resistance and downtime. Jack makes an informed decision and does not use XF due to the lack of decent and native importers.

If Jack made the decision to go with XF by migrating from phpBB without knowing there is no direct converter then more fool him. Sorry, research makes up 90% of every implementation. Period. Jack needs to retire

sounds like for mysql restores and backups you want to use multi-threaded mysql backup/restore tool called mydumper http://www.mydumper.org/ it's 3x to 10x faster than mysqldump/restore http://vbtechsupport.com/1716/ but you'd have to had backed up database via mydumper to take advantage of multi-threaded restore speed up.

Woah that's awesome, can't believe I've never come across this. Thanks for sharing!

This is where it's nice being on a cloud server setup that's billed hourly. Increase the resources to the max allowed, process the import/rebuild, and then decrease it back to normal.

You can install mydumper through yum, from Axivo repository:

Right now is available on Redhat 5 repository, I will have that built for Redhat 6 when I get a bit of free time on hand.
When RM will be released, I will be able to build an auto importer from Sqlite to MySQL, so the repodata is automatically displayed into categories, allowing everyone to see what the repository contains. Sure thing you can list the contents now with yum, but it will look fancier in RM.

Dump Usage:

Code:

$ mydumper -?
Usage:
  mydumper [OPTION...] multi-threaded MySQL dumping
 
Help Options:
  -?, --help                  Show help options
 
Application Options:
  -B, --database              Database to dump
  -T, --tables-list          Comma delimited table list to dump (does not exclude regex option)
  -o, --outputdir            Directory to output files to, default ./export-*/
  -s, --statement-size        Attempted size of INSERT statement in bytes, default 1000000
  -r, --rows                  Try to split tables into chunks of this many rows
  -c, --compress              Compress output files
  -e, --build-empty-files    Build dump files even if no data available from table
  -x, --regex                Regular expression for 'db.table' matching
  -i, --ignore-engines        Comma delimited list of storage engines to ignore
  -m, --no-schemas            Do not dump table schemas with the data
  -l, --long-query-guard      Set long query timer in seconds, default 60
  -k, --kill-long-queries    Kill long running queries (instead of aborting)
  -b, --binlogs              Get the binary logs as well as dump data
  -d, --binlog-outdir        Directory to output the binary logs to, default ./export/binlogs/
  -h, --host                  The host to connect to
  -u, --user                  Username with privileges to run the dump
  -p, --password              User password
  -P, --port                  TCP/IP port to connect to
  -S, --socket                UNIX domain socket file to use for connection
  -t, --threads              Number of threads to use, default 4
  -C, --compress-protocol    Use compression on the MySQL connection
  -V, --version              Show the program version and exit
  -v, --verbose              Verbosity of output, 0 = silent, 1 = errors, 2 = warnings, 3 = info, default 2

Restore Usage:

Code:

$ myloader -?
Usage:
  myloader [OPTION...] multi-threaded MySQL loader
 
Help Options:
  -?, --help                        Show help options
 
Application Options:
  -d, --directory                  Directory of the dump to import
  -q, --queries-per-transaction    Number of queries per transaction, default 1000
  -o, --overwrite-tables            Drop tables if they already exist
  -B, --database                    An alternative database to restore into
  -e, --enable-binlog              Enable binary logging of the restore data
  -h, --host                        The host to connect to
  -u, --user                        Username with privileges to run the dump
  -p, --password                    User password
  -P, --port                        TCP/IP port to connect to
  -S, --socket                      UNIX domain socket file to use for connection
  -t, --threads                    Number of threads to use, default 4
  -C, --compress-protocol          Use compression on the MySQL connection
  -V, --version                    Show the program version and exit
  -v, --verbose                    Verbosity of output, 0 = silent, 1 = errors, 2 = warnings, 3 = info, default 2

This is how I backup the database:

It will create a /export-20120505-004931 directory where your backup is present.

Jack wears kilts:

Jack - was too young and inexperienced using forums really to attempt converting a database himself.

Thanks, I'm more of a Debian man myself

I used to prefer CentOS to Debian, and then I gave Debian an honest shot, and I've never gone back. It's so much more secure and stable, and it just *feels* more robust. Everything about its nature and structure makes so much sense that I do everything administrative via command-line, whereas I used to use a lot of stuff like DirectAdmin back on CentOS. And you have to love that it's community-driven. Debian updates to the next version when the community feels it's a new product that is whole and ready, whereas CentOS moves forward when the shareholders/board members say so. Debian represents what I think all Linux flavors *should* be, the whole open-sourced philosophy behind its kernel's conception. But that's the beauty, right? That anyone can choose what their Linux is and how it works. Also, Debian names its releases after Toy Story characters, which I feel adds a level of humor and humanism to it that I can't help but respect. Also, aptitude is *so* much better than yum and rpms. I can't tell you how many times I've had a working system, tried to install something, and had it all go haywire. It's honestly easier to compile more obscure things on CentOS from source than it is sometimes to try to use either of the native package managers. Any time I've had problems with aptitude/apt-get, its built-in commands for fixing itself worked wonders.

That all said, both CentOS and Debian are great operating systems for servers, resource-wise. I just greatly prefer Debian.

On-topic: I don't think this is going anywhere, but I don't think you all should be arguing. Rather than disagree or try to tell people that mods might close their thread, just be polite and constructive, or say nothing. If a mod is going to close the thread, let them, and let it be because of the thread itself, rather than everyone stooping to childish levels arguing. Leave staff decisions to staff- no one likes would-be stand-ins with no authority trying to tell others what to do. :-/

I know a site (not mine) that would be interested in moving toward XenForo and is currently using phpBB

But with over 1 Billion post and 27 Million members; that maybe an issue.

At that number it "may be" an issue regardless of what software you're moving to Are you sure you're not exaggerating those numbers?

has

2,048,129,272

articles posted with

26,013,251

registered users.

IF such a change took place; it would not be until late 2012 or 2013

So stop keeping us all in suspense, what's the name of the forum?

Impressive, that'll be quite a challenge.

http://www.gaiaonline.com/forum/

It is only talk. No official word and I have no doubt it will be denied.

Doubt they'll convert to XenForo, they don't even use phpBB as such anymore. That's just a "fallacy people like to claim saying the biggest board on the web uses phpBB" Once read a long article about that community written by the owners of it, they pretty much stripped what was phpBB out and built their own (everything) for it. They even trim away god knows how many posts each day from the databases(s). They have numerous data-centres running that site, otherwise they'd far exceed those posting figures.

Yeah at that size you kind of HAVE to customize the software to a great extend. Most bulletin boards do support scaling across servers but rarely are they fully optimized for that sort of setup.

Stripped it of a lot of code (A LOT is an understatement) and added a few optimized things along the way. You are correct.

But at its core it is still an underline of phpBB. And uses more resources alone (idle) vs XenForo (stripped).

There is "an idea" (thought) of switching. It is only an idea and maybe will not happen at all.

But that concept will not progress past "an idea" until the current legal issues (Internet Brands vs XenForo) are a thing of the past. Even then, the admin(s) would need to "play" with things and see what possible things could be done.

It is only a thought at this time. Nothing more.