Tuesday, June 9, 2015

SourceForge is a long established web-based service that
offers source
code repository, downloads mirrors, bug tracker and other features. It
acts as a centralized location for software developers to control and
manage free and open-source software development.
SourceForge has been recently touting
controversy with a bizarre move to added bundled commercial
projects with 'unmaintained' code from open source projects; in
particular GIMP was affected. Following media
outrage, SourceForge has since vowed to discontinue this practice,
although there remain other practices that are questionable to open
source developers, such as the transfer of project pages they deem are
inactive, and malvertising. Is it time for developers
to look elsewhere to host projects? Fortunately, there are some
excellent alternatives.

GitHub

GitHub is currently the world’s largest, and most popular code hosting
site. It is web-based and uses Git, an open-source version
control system that was started by Linus Torvalds, the principal force
behind the Linux kernel.
GitHub provides distributed revision control and source code
management (SCM) functionality of Git as well as adding its own
features. It offers a web-based graphical interface and desktop as well
as mobile integration. It also gives developers access control and
several collaboration features.
Features include:

SSL, HTTPS, and SSH data transmission and two-factor
authentication are core elements of security at GitHub

Applications and tools that integrate with GitHub

Testimony to its popularity, GitHub has over 23 million
repositories.
Website: github.com

Bitbucket

Bitbucket is a Git and Mercurial based source code management
and
collaboration solution in the cloud. Bitbucket is written in Python
using the Django web framework.
Features include:

Simple to set up and use even for teams new to Git or
Mecurial

Pull requests, commit histories, and code reviews

Hold discussions right in the source code with inline
comments

Good user interface and tools

Issue tracking

Wiki

Web hosting

Binary downloads

Free public repositories

Unlimited private repositories

Integrates with many APIs and services

Bitbucket restricts you to work with only 5 people for free.
Website: bitbucket.org

GitLab

GitLab is a web-based Git repository manager with code
reviews, issue tracking, activity feeds, wikis. GitLab is close to
GitHub, but GitLab is released under an open source license (MIT
license).
GitLab is used by more than 100,000 organizations, and can
cope with 25,000 users on a single server. A subscription gives you
access to the company's support team and to GitLab Enterprise Edition
that contains extra features aimed at larger organizations.
Features include:

Fossil

Fossil is a simple, high-reliability, distributed software
configuration management system. It is released as a single
self-contained stand-alone
executable. Being distributed, Fossil requires no central server.
Features include:

Monday, June 1, 2015

Database replication is a technique where a given database is copied
to one or more locations, so that the reliability, fault-tolerance or
accessibility of the database can be improved. Replication can be
snapshot-based (where entire data is simply copied over to another
location), merge-based (where two or more databases are merged into
one), or transaction-based (where data updates are periodically applied
from master to slaves).
MySQL replication is considered as transactional replication. To
implement MySQL replication, the master keeps a log of all database
updates that have been performed. The slave(s) then connect to the
master, read individual log entries, and perform recorded updates.
Besides maintaining a transaction log, the master performs various
housekeeping tasks, such as log rotation and access control. When new
transactions occur and get logged on the master server, the slaves
commit the same transactions on their copy of the master database, and
update their position in the master server's transaction log. This
master-to-slave replication process is done asynchronously, which means
that the master server doesn't have to wait for the slaves to catch up.
If the slaves are unable to connect to the master for a period of time,
they will download and execute all pending transactions when
connectivity is re-established.
Database replication allows one to have an exact copy of a live
database of a master server at another remote server (slave server)
without taking the master server offline. In case the master server is
down or having any trouble, one can temporarily point database clients
or DNS resolver to the slave server's IP address, achieving transparent
failover. It is must be noted that MySQL replication is not a backup solution.
For example, if an unintended DELETE command gets executed in the
master server by accident, the same transaction will mess up all slave
servers.
In this article, we will demonstrate master-slave based MySQL
replication on two Linux computers. Let's assume that the IP addresses
of master/slave servers are 192.168.2.1 and 192.168.2.2, respectively.

Setting up a Master MySQL Server

This part will explain the steps needed on the master server.
First, log in to MySQL, and create test_repl database.

After exiting the MySQL server, edit my.cnf file using your favorite text editor. my.cnf is found under /etc, or /etc/mysql directory.

# nano /etc/my.cnf

Add the following lines under [mysqld] section.

1

2

3

4

5

6

[mysqld]

server-id=1

log-bin=master-bin.log

binlog-do-db=test_repl

innodb_flush_log_at_trx_commit=1

sync_binlog=1

The server-id option assigns an integer ID (ranging from 1
to 2^23) to the master server. For simplicity, ID 1 and 2 are assigned
to the master server and the slave server, respectively. The master
server must enable binary logging (with log-bin option), which will activate the replication. Set the binlog-do-db option to the name of a database which will be replicated to the slave server. The innodb_flush_log_at_trx_commit=1 and sync_binlog=1 options must be enabled for the best possible durability and consistency in replication.
After saving the changes in my.cnf, restart mysqld daemon.

# systemctl restart mysqld

or:

# /etc/init.d/mysql restart

Log in to the master MySQL server, and create a new user for a slave server. Then grant replication privileges to the new user.

A new user for the slave server is repl_user, and its password is repl_user_password.
Note that the master MySQL server must not bind to the loopback
interface since a remote slave server needs to log in to the master
server as repl_user. Check this tutorial to change MySQL server's binding interface.
Finally, check the master server status by executing the following command on the server.

mysql> SHOW MASTER STATUS;

Please note that the first and second columns (e.g.,
master-bin.000002 and 107) will be used by the slave server to perform
master-to-slave replication.

Setting up a Slave MySQL Server

Now it's time to set up the configuration of a slave MySQL server.
First, open my.cnf on a slave server using your favorite text editor, and add the following entries under [mysqld] section.

With the above commands, the local MySQL server becomes a slave
server for the master server at 192.168.2.1. The slave server then
connects to the master server as repl_user user, and monitors master-bin.000002 binary log file for replication.
The above screenshot shows the status of the slave server. To find
out whether replication is successful, take a note of three fields in
the status output. First, the Master_Host field is supposed to show the IP address of the master server. Second, the Master_User field must display the user name created on the master server for replication. Finally, the Slave_IO_Running should display "Yes".
When the slave server starts working, it will automatically read the
database log in the master server, and create the same table(s) and
entries if they are not found in the slave. The screenshot below shows
that the slave server has the same entries in the employee
table as the master server (see the red square). When the city value is
updated from the master server, the change is automatically replicated
to the slave server (see the yellow square).