Author Topic: Forum Outage  (Read 55723 times)

0 Members and 1 Guest are viewing this topic.

Offline gnif

  • Administrator
  • *****
  • Posts: 1675
  • Country: au
Re: Forum Outage
« Reply #125 on: November 25, 2013, 04:20:09 am »
The heap/memory tables seem ideal for the users online table. How many other tables are there that get corrupted and are they as suitable for heap/memory? Are they all just temp data tables?

Were the performance issues related to the time earlier this year when RAM was inadequate? Would you expect the increased RAM to accommodate the increase in memory use after converting the tables or will still more RAM be needed?

What are the pros/cons of a Mysql slave? Would it facilitate a faster recovery in the event of a primary database outage? Would you need an extra level of network infrastructure to detect and switch to the slave if an automated switchover were to occur?

The heap/memory tables will only take up a few hundred kilobytes, not enough to worry about. We can only convert the tables that have temporary data in them, and even then, we will only bother with tables that are very active. Performance was ram related earlier this year, we have enough ram free to allocate some to a heap table, this wont be a problem.

A slave database is running on a different server, every time an update occurs, the update gets replicated across to the slave giving us a database backup that is current as of the crash/failure of the master server. This means that in the event of data loss, we can recover pretty much up to the second of the outage, instead of X hours ago when the last backup was performed. This is not the only function of a slave database instance, but it would suit Dave's requirements quite nicely. Obviously we will still need to perform daily backups of the database in case a bad SQL statement is executed which gets replicated to the slave.
 

Offline EEVblogTopic starter

  • Administrator
  • *****
  • Posts: 37717
  • Country: au
    • EEVblog
Re: Forum Outage
« Reply #126 on: November 25, 2013, 05:24:30 am »
A slave database is running on a different server, every time an update occurs, the update gets replicated across to the slave giving us a database backup that is current as of the crash/failure of the master server. This means that in the event of data loss, we can recover pretty much up to the second of the outage, instead of X hours ago when the last backup was performed. This is not the only function of a slave database instance, but it would suit Dave's requirements quite nicely. Obviously we will still need to perform daily backups of the database in case a bad SQL statement is executed which gets replicated to the slave.

That sounds like the go.
How easy is it to set up a slave database?
 

Offline gnif

  • Administrator
  • *****
  • Posts: 1675
  • Country: au
Re: Forum Outage
« Reply #127 on: November 25, 2013, 05:48:56 am »
A slave database is running on a different server, every time an update occurs, the update gets replicated across to the slave giving us a database backup that is current as of the crash/failure of the master server. This means that in the event of data loss, we can recover pretty much up to the second of the outage, instead of X hours ago when the last backup was performed. This is not the only function of a slave database instance, but it would suit Dave's requirements quite nicely. Obviously we will still need to perform daily backups of the database in case a bad SQL statement is executed which gets replicated to the slave.

That sounds like the go.
How easy is it to set up a slave database?

It is a bit of a fiddle, but not too bad, I will omit further information about the configuration publicly for security reasons :).
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf