|Showing entries 1 to 10|
Many CMS-backed sites are built using MySQL and are launched on cloud infrastructure. In order to mitigate down-time due to regional outages, it is advisable to create a geo-distributed redundancy topology in both the app layer as well as within the database. GenieDB makes it very easy to set up multiple MySQL database servers around the world that are automatically kept synchronized as data is changed on any of the nodes. The database nodes are typically paired 1-on-1 with an app or web server. Some of our customers use the app servers to dish out their CMS backed sites. The database is kept synchronized, but the customers still need to find a way to keep the media content that they use to be available on all these app/web servers. Below is a simple setup that can be easily configured within a very small budget and provides high availability[Read more...]
Catching up on our reading today, we saw a blog post from Chris Stevens, the multi-faceted VP of Engineering at Traxo, technology consultant, and Full Stack developer. In his post, he notes some of the impressive new database technologies he’s seeing lately in tech blogs and on the conference circuit.
Chris says that when it makes sense he advises his clients to look at non-relational datatstores, but for a number of reasons he works with MySQL wherever possible. Many of his clients looking to run globally distributed applications often need to distribute the database across more than one data center (geo-distribution) for fault tolerance and localized performance.
“Globally distributed applications often require localized performance,” he said in his post. “We can do[Read more...]
Standard MySQL is configurable such that a single master server can be clustered with a number of read-only slave servers. To enable this master-slave replication, master’s transaction logs are communicated to the slaves (log shipping). Log shipping is a form of asynchronous replication. Under this configuration, the data on the slave always remains behind the master, a condition referred to as slave lag or replication lag. The extent of the slave lag depends on workload, network bandwidth and network latency. Database reads can be served out of the slaves, assuming the application has been designed to tolerate the slave lag and requisite staleness of data (eventual consistency), which can at times be variable and opaque. MySQL master-slave replication offers the possibility of promoting a slave to become the new master[Read more...]
Scenario Master – Master replication
MasterA is a client facing server
MasterB is a warm standby server (read only)
MasterB restarted abruptly and when instances were braught back up MasterA (it’s slave) was showing the following error:
MasterA has the following error in show slave status:
Last_IO_Error: Got fatal error 1236 from master when reading data from binary log: ‘Could not find first log file name in binary log index file’
Slave: stop slave;
Master: flush logs
Master: show master status; — take note of the master log file and master log position
Slave: CHANGE MASTER TO MASTER_LOG_FILE=’log-bin.00000X′, MASTER_LOG_POS=106;
Slave: start slave;
It’s been a long time since we’ve started this project and it is time to make a checkpoint. So, I’ve decided to release final 1.0 version and make 1.X branch stable while all serious development with deep architectural changes will be done 2.X branch (trunk at this moment).
Changes from previous release:
As always, if you have any questions/suggestions, post them here or in mmm-devel mail list.
|Showing entries 1 to 10|