Jan 12

How to Move MySQL Data Directory to New Location on CentOS

In default MySQL installation, Data Directory pointed to “/var/lib/mysql/” . As a best practice, it’s recommended to move Data directory to new location
which contains more disk space than default root partition. This tutorial guides you how to Move MySQL data directory to new location on CentOS or RHEL. Even data directory contains data, you can still move it to another location, but you have to be careful if you try this on production environment. Let’s go through it quickly :-)

1) Prepare new location

2) Find current Data Directory location

you can get it from /etc/my.cnf if it’s defined on. To verify it or it’s not mentioned on configuration file, most probably use default location.
let’s find that out

log into mysql server and run following command

As per above current location is “/var/lib/mysql/

3) Shut down MySQL server

4) Copy MySQL data directory to new location

now new location is /opt/newmysql_datadir/mysql

5) Modify SELinux to allow MySQL to use the different (non default) path

This step is mandatory if your system enabled with SELinux, otherwise you can ignore this step

6) Update new settings to my.cnf

Find the line in the [mysqld] block that begins with datadir=. Change the path which follows to reflect the new location. In addition to that, socket was previously located in the data directory,  we’ll need to update it to the new location

It should like below after updating.

Apart from that we’ll need to add configuration for the MySQL client.  Insert the following settings at [client]  block which is at the bottom of the file.

7) Start MySQL server

If it won’t start  , you may need to troubleshoot by checking  MySQL  error log. You can make comments any issues if you have faced here, I’m always happy to assist you !!

Dec 23

Configure NTP server (Chrony) on CentOS / RHEL7

Classic NTP is replaced by Chrony and  CentOS / RHEL7 is no longer use it, instead it’s default is Chrony.  The Chrony is a different implementation of the network time protocol (NTP) than the network time protocol daemon (ntpd)  that is able to synchronize the system clock faster and with better accuracy than ntpd. Here is little comparison between Chronyd and NTPd

 

Things chrony can do better than ntp:

  • chrony can perform usefully in an environment where access to the time reference is intermittent. ntp needs regular polling of the reference to work well.
  • chrony can usually synchronise the clock faster and with better time accuracy.
  • chrony quickly adapts to sudden changes in the rate of the clock (e.g. due to changes in the temperature of the crystal oscillator). ntp may need a long time to settle down again.
  • chrony can perform well even when the network is congested for longer periods of time.
  • chrony in the default configuration never steps the time to not upset other running programs. ntp can be configured to never step the time too, but in that case it has to use a different means of adjusting the clock (daemon loop instead of kernel discipline), which may have a negative effect on accuracy of the clock.
  • chrony can adjust the rate of the clock in a larger range, which allows it to operate even on machines with broken or unstable clock (e.g. in some virtual machines).
  • chrony is smaller, it uses less memory and it wakes up the CPU only when necessary, which is better for power saving.

 

Things chrony can do that ntp can’t:

  • chrony provides support for isolated networks whether the only method of time correction is manual entry (e.g. by the administrator looking at a clock). chrony can look at the errors corrected at different updates to work out the rate at which the computer gains or loses time, and use this estimate to trim the computer clock subsequently.
  • chrony provides support to work out the gain or loss rate of the real-time clock, i.e. the clock that maintains the time when the computer is turned off. It can use this data when the system boots to set the system time from a corrected version of the real-time clock. These real-time clock facilities are only available on Linux, so far.

 

Things ntp can do that chrony can’t:

  • ntp supports all operating modes from RFC 5905, including broadcast, multicast, and manycast server/client. However, the broadcast and multicast modes are inherently less accurate and less secure (even with authentication) than the ordinary server/client mode and should generally be avoided.
  • ntp supports the Autokey protocol (RFC 5906) to authenticate servers with public-key cryptography. Note that the protocol has been shown to be insecure and it will be probably replaced with an implementation of the Network Time Security (NTS) specification.
  • ntp has been ported to more operating systems.
  • ntp includes a large number of reference clock drivers. chrony relies on other programs (e.g. gpsd) to access the timing data via the SHM or SOCK driver.

 

So let’s look at how to Configure NTP server (Chrony) on CentOS / RHEL7

1) Install Chrony

 

2) Change servers for synchronization

this step is optional, you can skip if do not want to customize NTP servers

 

then commented out default servers and add your own NTP servers .

 

3) Disable NTP server and start chronyd

 

4) Verify NTP sources

chronyc sources -V

chronyc sources -V

5) Verify NTP time synchronization

 

Have a Nice day 😀

Sep 03

Redirect non-www requests to www using AWS Route 53

Many web masters prefer to redirect non-www request to www. There are lots of different approaches for that and most famous one is using 301 redirection on the web server to handle this redirect part. Then what happen is, server must need to put extra processing for this redirection request.  If the server have to handle thousands of request, it would not be efficient method at all. If your domain NS (name servers) is hosted with AWS Route53, you can use their own proprietary alias “record” to solve this problem. The traditional DNS, you cannot do it at all and you have to used 301 redirect instead as I mentioned earlier. Other advantage of the redirection is SEO improvement as some search engine recognize www and non-www as two different web sites and this cause to penalize the domain considering website has duplicate content.
Here I’m going to demonstrate how to redirect non-www requests to www using AWS Route 53. So let’s look at.

1) create S3 bucket for naked domain

ex:- domain.com

2) Configure non-www request to www on AWS S3

i) Highlight previously created bucket

ii) From “Properties” expand “Static Website Hosting”

iii) Select “Redirect all request to another host name”

non-www to www redirect using AWS s3

3) Configure AWS Route53

i) select your domain from “hosted zones”

ii) point www to your server ip or ELB (Elastic Load Balancer) by creating new records

you may click on “Create Record Set” button

iii) select your naked domain record from the list

list may contains other records such MX, TXT as well, but you must select just your domain.
ex:- example.com.

when you select it, you can set following parameters from right hand side panel.

select Type as “A – IPV4 address” from drop down
select Alia as “YES
select Alias Target as previously created S3 bucket from drop down.

AWS Route53 Alias records

 

that’s how to do that. Comment here If you are having any question at all !    :-)

Older posts «

Fetch more items