Wednesday, February 15, 2017

How to install datamapper mediator in WSO2 API Manager 2.1.0

WSO2 API Manager 2.1.0 was released recently with outstanding new features and many improvements and bug fixes. There are many mediators supported by WSO2 API Manager out of the box and some of them you should have to install as features.

This blog post will guide you on how to install datamapper mediator as a feature in WSO2 API Manager 2.1.0.

Download WSO2 API Manager 2.1.0 from product web page if you haven't done already.

Please follow the below steps to install the datamapper mediator.

1. Extract the product and start the server.

2. Go to https://<host_address>:9443+offset/carbon and login with admin credentials.

3. Go to Configure > Features > Repository Management.

4. Click on "Add Repository ".

5. Give a name to the reposiory,  and add the P2 repository URL which is as the URL and click add.

This will add the repository to your API Manager.

6. Now click on Available features tab, un-tick "Group features by category" and click on "Find Features" button to list the features in the repository.

7. Filter by feature name "datamapper" and you will get two versions of datamapper mediator Aggregate feature. Those are mediator version 4.6.6 and 4.6.10.

The relevant mediator version for API Manager 2.1.0 is Mediator version 4.6.10.

8. Click on the datamapper mediator Aggregate feature with version 4.6.10 and install it.

9. Allow restarting the server after installation.

This will install datamapper server feature and datamapper UI feature in your API Manager instance. Now you have to install Datamapper engine feature. To do that follow the below steps.

Installing datamapper engine feature : 

1. Go to WSO2 nexus repository :

2. Type "org.wso2.carbon.mediator.datamapper.engine" in search bar and search for the jar file.

3. You will find the set of releases of the org.wso2.carbon.mediator.datamapper.engine archives.

4. Select 4.6.10 version from them, select the jar from the achieves and download the jar.

5. Go to <APIM_HOME>/repository/components/dropins directory in your API Manager instance and copy the downloaded jar  (org.wso2.carbon.mediator.datamapper.engine_4.6.10.jar) in it.

6. Restart WSO2 API Manager.

Now you have an API Manager instance where you have successfully installed datamapper mediator. 

Go ahead with mediation !!!

Sunday, June 19, 2016

How to use Non-English Languages with WSO2 API Manager

Hello All,
When I am writing this blog WSO2 API Manager 2.0.0 is about to release and we have already released our beta version. I thought to let you know about one interesting feature of it that comes with this release. That is non- English character support in WSO2 API Manager Store and Publisher. 

Specifically, now with WSO2 API Manager 2.0.0 you will be able to use your own language to create APIs and their descriptions etc shown in following image. 

API published which has created with non-English characters

You can sign up with non-English usenames, create applications in API Store with any of the languages you want and can generate the application access tokens. No worries !!!

Application with non-English

Self Signup with non-English

Login with Non-English username 

Now let's see what you need to configure to get this feature in your API Manager environment. 

Embeeded H2

With the embedded H2 database that comes with WSO2 API Manager you can do it without a hassle.  That means there you have nothing to configure. Just create the databases. Run your API Manager product with -Dsetup and you got it.


With MySQL versions below 5.7, when creating the databases you need to give the character set as UTF-8. Assume that you are using two databases here; one is for apimgt database (WSO2AM_DB) and other is for registry database (WSO2CARBON_DB). So, the following steps show how you can do this.

1. Start MySQL Server and login with the credentials.
2.Create the apimgt database with UTF-8 character set and collation as follows.

                create database apimgtdb CHARACTER SET utf8 COLLATE utf8_Unicode_ci;

3. Create Registry database with UTF-8 character set and collation as follows.

               create database regdb CHARACTER SET utf8 COLLATE utf8_Unicode_ci;

4. Then Configure your databases with WSO2 API Manager. 

      i. Open <AM_HOME>/repository/conf/datasources/master-datasources.xml file and configure your database as shown bellow replacing the default configuration comes for the WSO2AM_DB and WSO2CARBON_DB.


       <description>The datasource used for registry and user manager</description>
       <definition type="RDBMS">
               <validationQuery>SELECT 1</validationQuery>

There make sure to give the character Encoding as UTF-8 as highlighted above in the connection URL to support your database connection for Unicode character encoding.


            <description>The datasource used for API Manager database</description>
            <definition type="RDBMS">
               <validationQuery>SELECT 1</validationQuery>

Now you have done with the configuration. Start WSO2 API Manager with -Dsetup. 
Well, Now you can create APIs with non-English characters and Publish to the API Store like in above picture. And also you can create applications, get self sign up etc with using your own language.

How can you do this for your existing database ?

The steps that I have shown above are for a situation where you are beginning with API Manager 2.0.0 database scripts. Well, what if you have the database with data already ? or you want to migrate with existing data ? Ok, I have a solution for that as well. 

Steps :

1. Run the following alter scripts against your WSO2AM_DB.


2. Get a back up of the database.

3. Create a new database using the following command.

create database <new_database_name> CHARACTER SET utf8 COLLATE utf8_Unicode_ci; 

4. Restore the database backup which has previously taken to the newly created database.

5. Point the new database name in the master-datasources.xml file in <AM_HOME>/repository/conf/datasource directory under particular DB'connection URL.

6. Repeat the steps 2,3,4,5 against the WSO2CARBON_DB also.

7. Start the server with -Dsetup.

Ex. In Ubuntu :         sh -Dsetup
You are done.

MySQL 5.7+

When using MySQL 5.6 or previous versions, you need to keep the VARCHAR length of the data types limited below 256 which are used as PRIMARY keys, FOREIGN Keys or UNIQUE Keys. That is due to a limitation exists in MySQL  product. But with MySQL 5.7 and above versions this issue has fixed. Therefore you can have your database with non-English stuff just by creation the database with UTF-8 encoding type.
If you are using MySQL 5.7+, Follow the below steps to get non-English character support.

1. Start MySQL Server and login with the credentials.

2.Create the apimgt database with UTF-8 character set and collation as follows.

                create database apimgtdb CHARACTER SET utf8 COLLATE utf8_Unicode_ci;

3. Create Registry database with UTF-8 character set and collation as follows.

               create database regdb CHARACTER SET utf8 COLLATE utf8_Unicode_ci;

4. Configure your master datasources.xml file same as described in above configuration under MySQL.

5. Start the server with -Dsetup.

If you are using an existing database, you do not need to run alter scripts against the data as like in MySQL 5.6 and previous versions. You can follow same steps described here and backup your database into the new database created.


By default PostgreSQL supports UTF-8 character encoding. Therefore if you are using PostgreSQL you need not to do anything. You already have the support for non-English in your API Manager.

Oracle and Oracle RAC

Although you need to configure Oracle for UTF-8 character support for normal databases you use of you haven't done it in it's schema, the script for Oracle database which comes with WSO2 API Manager supports it by having the VARCHAR2 as the character datatype. Therefore for your existing database and also for new databases that you create with Oracle with API Manager 2.0.0, you have the chance to use non-English languages. Same like in PostgreSQL or H2 database you just need to create the database according to the documentation.

In this article I focused on elaborating the configuration procedure that you have to follow to get the non-English support feature. Hope you feel much more familiar with WSO2 API Manager with your own language. With new localization support feature that comes with WSO2 API Manager 2.0.0, it will be a more fantastic experience.

ok then, Until we meet again...

Thursday, April 7, 2016

Passive STS (WS Federation) with WSO2 Identity Server 5.0.0 : A step by step guide

This blog post will guide you step by step to configure WSO2 Identity Server’s Passive STS. Please note that I am using our sample client application here for testing. The steps to be followed starting with downloading the WSO2 Identity Server will be described here.

Step 1 : Installing Product and the Service Pack 1

1. Create a directory in your local machine.
2. Download WSO2 IS 5.0.0 to and extract to the created directory.
3. Download Service Pack 1 [ ] and extract to the same above directory.
4. Install the service pack
The below steps will guide you to install the Service pack 1 in a fresh WSO2 IS 5.0.0 pack. If you need to install the service pack in the production environment where WSO2 IS is already running please refer the documentation on Installing the Service Pack in  production environment and follow the steps described there.

Installing the service pack in a fresh identity Server : 

Go to WSO2-IS-5.0.0-SP01 directory (will be referred as <SP_HOME> hereafter in this documentation) through command line.
Run Service pack installation script.

On Linux/Unix: $ sh
             On Microsoft Windows: \> install_sp.bat

Navigate to bin folder of wso2is-5.0.0 directory (  wso2is-5.0.0 directory will be referred as <IS_HOME> here after in this documentation) and start the server.

On Linux/Unix: $ sh -Dsetup
On Microsoft Windows: \> wso2server.bat -Dsetup

Open the <IS_HOME>/repository/logs/patches.log file and look for the following line. If you find it, that means the service pack has been applied successfully.
INFO {org.wso2.carbon.server.util.PatchUtils} - Applying - patch1016

Step 2 : Configure the Client application

Please note that in this section Sample client provided for WSO2 IS to demonstrate the configuration steps is used to describe the steps here. You can use your own client application and do the configuration steps accordingly as like below.

IdpUrl        :     e.g. https://localhost:9443/passivests
realm        :     e.g. PassiveSTSSampleApp

URL for Logout :
https://<IS URL>/commonauth?commonAuthLogout=true&type=passivests&sessionDataKey=xxxxxxx&commonAuthCallerPath=<redirectURL>&relyingParty=<relying party name>


Configure the Passive STS Sample 

1. Checkout the sample client application from the SVN location using following command to a directory. (You can use the same directory created above).

2. Go to the checked out directory ( will be referred as <SAMPLE_HOME> hereafter in this documentation) and modify <SAMPLE_HOME>/src/main/webapp/WEB-INF/web.xml file as follows.

  1. Specify  idpUrl  as the URL of Identity Server's Passive STS. The following is an example.


  1. Specify the replyURL as the URL of the web app. The following specifies PassiveSTSSampleApp as the web app.


  1. Specify the  realm . This should be a unique identifier for the web app as seen in the example below.


Step 3 : Configuring Identity Server for Passive STS

1. Log into WSO2 Identity Server and go to Service Providers ->Add in the Main menu in the management console.

2. Enter a unique name for the service provider and click Register. The following form appears.  

3.Expand the Inbound Authentication Configuration -> WS-Federation (Passive) Configuration section and provide the Passive STS Realm.

Note :  Here you should give the same realm name that is configured in the client application’s web.xml

4. You can add claims through Claim Configuration Tab. These claim will be sent to STS client application.

5. Click Update.

Step 4 : Deploying the sample on Apache Tomcat

Please note that the following steps are described assuming that you are using the sampleSTS application checked out from the svn location. If you are using your own client application which is deployed somewhere else you can access that link and follow step 7 only to log in to the application.

1. Build the sample's .war file.
2. By navigating inside the <SAMPLE_HOME> directory where the pom.xml file is located and running the following command.
mvn clean install
3. Copy the PassiveSTSSampleApp.war file located in the <SAMPLE_HOME>/target directory and paste a copy of it in the <Tomcat_Home>/webapps directory. 
4. Navigate inside the [Tomcat_Home/bin] directory in the command line and run sh run command to start the server.
5. On your browser, access the following link: http://localhost:8080/PassiveSTSSampleApp/index.jsp 
6. Enter user credentials and you will be redirected to the IS Passive STS Service as shown in the following login.

STS-client-app-login.png - Latest 06/Apr/16 05:42 PM IST - Kugathasan Abimaran

And you can access the app after login as follows.

STS-claim-in-client-app.png - Latest 06/Apr/16 05:40 PM IST - Kugathasan Abimaran

Friday, October 30, 2015

Enabling User Password Recovery for WSO2 API Manager with WSO2 Identity Server - Part 1

Any of the WSO2 API Manager versions released so far does not have the capability of user password recovery. If the API Manager users completely forget their password, they do not have a way to recover it. However WSO2 Identity Server have this feature implemented as a service called UserInformationRecoveryService. This blog post will explain how to use this password recovery feature of WSO2 IS in WSO2 API Manager. I will demonstrate the service calls through soap UI here.

User Information Recovery API

WSO2 Identity Server has given an API to recover forgotten/lost password in several ways. Those are as follows.

1. Recover with notification : password recovery by using email based notifications. An email is sent to the user's email account through axis2 mail transport.
2. Recover with Secret Questions : By obtaining answers for some challenge questions by invoking UserIdentityManagementAdminService.
3. User Account Recovery : helps to recover username of the account if the user has forgotten it.

All the above recovery processes are secured with captcha verification. In this blog post I will describe how the first option can be enabled in WSO2 API Manager 1.8.0.

Installing WSO2 Identity Server Feature in API Manager

First of all if we want to have the password recovery capability in WSO2 API Manager you have to install the Account Recovery and Credential Management Feature of WSO2 Identity Server in WSO2 API Manager. Please follow the below steps to install the feature.

Steps : 
1. Start the Server and log in to the Management Console of WSO2 API Manager

For more information on downloading WSO2 API Manager, installing it and about installation prerequisites please refer WSO2 API Manager Documentation.

2. Navigate to the Configuration menu and go to Features --> Repository Management and add repository with a relevant name.  e.g. credential-mgt

3. Give the following as the repository URL This is the related P2 repository for the feature.

4. Click on Find the features and select Account Recovery and Credential Management 4.2.2 and click install.

5. Accept Licence Agreement and finish installing the feature.

Configuring WSO2 API Manager for User Information Recovery

After installing the feature follow the documentation on Recover with Notification in WSO2 Identity Server and configure WSO2 API Manager for User Information Recovery. Consider <IS_HOME> mentioned in the documentation as <APIM_HOME> which is the installation directory of product API Manager.

Now WSO2 API Manager has the capability of calling the UserInformationRecoveryService.

Getting the WSDL of UserInformationRecoveryService

Steps : 
1. Stop the Server.
2. Go to <APIM_HOME>/repositiory/conf/carbon.xml and make <HideAdminServiceWSDLs> property false as follows.

2. Start the Server and access the WSDL of UserInformationRecoveryService through following link.

Now what you have to do is calling the relevant service methods in order. Follow the service methods mentioned in documentation and call the service methods.

To use this feature as an existing feature in WSO2 API Manager either you have to implement a jaggery module in API Manager Store or you have to create a separate web app to be redirected from within API Manager Store. however you can check how this is working using Soap UI.

Please go through my next blog post to see how you can call the UserInformationRecoveryService through Soap UI and change the password of a user.

Thursday, July 2, 2015

WSO2 API Manager Distributed Architecture : Configuration Tips (Ubuntu)

Hello all....!

I thought to write another blog on WSO2 API Manager. Well, you may have a basic understanding on what is WSO2 API Manager. If not you can go through my previous blog post or refer to the WSO2 API Manager documentation.

When I am writing this blog it is only two weeks after the WSO2 API Manager 1.9.0 release and now we are working on releasing the next versions of WSO2 API Manager. In the  version 1.9.0  I could work closely on the distributed Architecture of WSO2 API Manager.

There are lot of configurations to do when creating a distributed setup for WSO2 API Manager and you will get the chance to use several other WSO2 Products as well. Other than that you have to fulfill some prerequisites before installing the products.

The intention of this blog post is not to describe how to create an API Manager Distributed setup. To get that information you can refer to the WSO2 Documentation. My intention is to guide you in some configuration steps of the distributed setup to save your time finding here and there what to do and how to do by pointing out where are the places you might do mistakes and  how to work with the remote machines when configuring the instances.

First of all lets get a basic understanding on the distributed architecture of WSO2 API Manager.

API Deployment Distributed Architecture

There are four main components in the WSO2 API Manager distributed setup. They may be one instance per each or more than one instance  (clustered/not clustered) according to the requirement.

1. API Gateway  - This is the component which manage the API calls by securing them and scaling them.

2. Key Manager - Responsible for the Key-related security operations

3. Publisher - Instance which is used by API providers to publish APIs, share documents, provision keys and gather feedback on the features

4. Store - Instance which is used by the consumers to do self sign up,  to subscribe the APIs, invoke them and interact with the API publishers.

Other than that you need a DBMS (e.g. MySQL Server) to create the three databases described in following.

Databases :

There are three databases we need to have for the cluster deployment architecture. Those are,

  • API Manager Database (Information about APIs and API sbscription details)
  • User Management Database  (Information about users and user roles)
  • Registry Database (Shared information between Publisher and Store)

Single Sign On Login with WSO2 Identity Server (WSO2 IS)

To enhance the efficiency, accessibility and for a better user experience you are encouraged to Configure the Publisher and Store in your distributed setup. You can follow the WSO2 documentation for SSO configuration to accomplish this task after setting up the cluster. For this we use another WSO2 Product : WSO2 Identity Server which manage the identities across internal, Shared an SaaS services.

In this particular situation, as an example this allows the authenticated users to access API Manager Store without repeatedly authenticating if the user is authenticated in API Manager Publisher in WSO2 API Manager.

Publishing Runtime Statistics with WSO2 Business Activity Monitor (WSO2 BAM)

To collect the runtime statistics of WSO2 API Manager and to analyse them you are encouraged to use another WSO2 Product which has developed to aggregate, analyse data and present information about business activities. WSO2 API Manager use this product to configure publishing the run time statistics about API related activities. Follow the WSO2 Documentation to Configure WSO2 API Manager with WSO2 BAM to publish API runtime statistics.

Load Balancing with nginx

For load balancing we used WSO2 Elastic Load Balancer (ELB) earlier. Now we encourage the customer to use Nginx for load balancing. To do Nginx configuration follow the WSO2 Documentation.

Now lets move into the important tips.

1. Access remote instances 

When configuring a distributed setup for WSO2 API Manager you need to access the remote instances through terminal. To access the remote machine you may have a key included in a .pem file. First of all you have to give the read and write rights to the .pem file

<path_to_pem_file>/chmod 600

Then you access the remote instance using the following command.

ssh -i <pem_file_name>.pem <remote_host_name>@<remote_host_ip> 
e.g. ssh -i permission.pem

You will log into the remote machine and you can work with it using terminal. 

2. Coping product binaries to remote machines 

Since we are using remote machines and we have to use several software products it is required to download those files to the machines or trasfer them. You can download the products to the remote machines through terminal using the following command.

wget "<download_link_to_the_file>"

wget ""

But this is a time consuming task. Therefore the proper solution is to copy the files to the remote machine through the SSH connection you built. To do that we use secure copy commands which allow coping files through an SSH connection. For that also you need the .pem file.

scp -i <path_to_pem_file>/<pem_file_name>.pem  <path_to_file_in_your_machine>/<file_to_copy> <remote_host_name>@<remote_host_ip>:<location_to_be_copied>

e.g. scp -i /home/API-deployment-Architecture/permission.pem

3. Installing prerequisites 

For each of the WSO2 product to run there is a set of prerequisites to be installed in the Machine which it is running. In this setup we are using WSO2 API Manager, WSO2 Business Activity Monitor and WSO2 Identity Server. To get more information on prerequisits got through installation prerequisites.

You need to install all these through the terminal. Following are the steps to install them.

Install  Java : 
Follow my this blog post to install Java in the remote machine.

Installing Maven : 
sudo apt-get install maven

By running above command you can install maven in the remote machine. To check the version execute the following command.

mvn -version

installing ActiveMQ : 

download ActiveMQ :

tar -zxvf apache-activemq-5.6.0-bin.tar.gz

go to bin folder of ActiveMQ and run get the read write permission.
chmod 755 activemq

start ActiveMQ :
sudo sh activemq start

test the installation
netstat -an|grep 61616

Since you are installing the binary distribution not building the source you do not need to install SVN client and if you do not compile and run the product samples in the remote machine you do not need to install Apache Ant. You need to install the SVN client in the remote machine where the deployment synchronization is going to be configured. Use the following command for that.

sudo apt-get install subversion

4. Installing MySQL Server 

Since you have to configure the three databases described above you have to install a database server. Assuming that you will choose MySQL server I will give the configuration tips. You can follow my previous post to install MySQL Server in your remote machines.

5. Port Offset

In this cluster setup you will have to run more than one WSO2 product in the same cluster and also more than one WSO2 product in the same machine. To avoid the port conflicts you have to make sure setting the port offset correctly by editing the <PRODUCT_HOME>/repository/conf/carbon.xml file.


According to the value that you set it increment the ports used by the server starting from the 9443 which is the default port.

6. Who need which ?

Another thing you need to understand when setting up this distributed architecture is that which component need which component to be connected together to perform. We configure WSO2 BAM to publish run time statistics. It is required by Gateway, Publisher, KeyManager and Store. We configure Single Sign On which is required or affected by Publisher and Store. We need load balancing of we are going to balance the load in the gateway cluster which manage the API calls.
Considering the databases, API Manager database is needed by Publisher, Store and KeyManager. But gateway do not need it. User Manager database and Registry database is needed by all the four components in the cluster. Likewise when doing the configuration we should have it in mind who need which.

7. Configuring databases  - username, password, database names, coping mysql files - bam do not need, but creating the database is needed for all, apim and registry db shoud run the query. proper db name in both xml and db

8. Configuring API Manager for Stats

properly setting the IP addresses in the API Manager configuration in stat configuration is needed to avoid errors. According to that Event Receiver configurations and Data Analyser Configurations should have the URL with IP address where the WSO2 BAM instance is running. Statistics summary datasource should be the URL of the Statistical database and the username password should be the username and password of your MySQL server.

9. Locating Database Driver 

Another main important point that you may have missed is that locate/save the MySQL JDBC driver in the product. According to the setup describing here since we ar eusing MySQL server we need connector to perform the database calls. Therefore in every WSO2 product you are using here you need to place MySQL JDBC Driver jar file in <PRODUCT_HOME>/repository/components/lib folder.

12. SVN based deployment synchronization

In the distributed setup we used to cluster the Gateway nodes (some times the key Manager as well) to be in one internal cluster domain with a Manager node and a set of worker nodes. It leads to set up the load balancing configurations in the gateway. For that enabling deployment synchronization in the manager node is essential. Registry-based Deployment Synchronizer does not work for WSO2 products based on Carbon 4.2.0 onwards. We are using SVN here. The deployment synchronizer uses this configuration to identify the manager and synchronize deployment artifacts across the nodes of a cluster. WSO2 Documentation on configuring SVN based deployment synchronizer will follow you through this process.

13. Updating known hosts

Make sure to update the host IP addresses with the host names in the machines that you wish to access the instances of the cluster setup. To that open the "hosts" file in the etc folder in the Ubuntu machine you are using  add the IP addresses and the host names as indicated in the following image.

vi /etc/hosts

For that you must log into the system root.

14. Configuring the databases: 

There are three main databases in the cluster deployment setup that we need to configure. Those are API Manager database, Registry database and User Management database. If you are using MySQL server you should create the databases and run the mysql script on it to create the schema of the databases.

mysql> \. mysql.sql

API Manager database : <APIM_HOME>/dbscripts/apimgt/mysql.sql
Registry database : <APIM_HOME>/dbscripts/mysql.sql
User Management database : <APIM_HOME>/dbscripts/mysql.sql

Other than that you need to configure the Statistical database for publishing statistics where you only need to create the database. When running WSO2 BAM instance it execute the relevant queries and create the database schema.

MySQL remote settings:

For all the instances in the cluster setup there need to be one API Manager database, one Registry database and one User Management database. Therefore we should the set the configuration by binding the address where the database is located in each of the instance.

For that open the my.cnf file in /etc/myql directory and give the IP where the database is located as the bind address. Then log into the mysql root and grant the permission to the database users to read and write to the database.

Grant permission :


You can check the access from the remote host with this command.

mysql -u root -h -p

This will give the remote access to the databases in the cluster setup.

Other than that, make sure the database names, URLs and the username and password are correctly configured in the master-datasources.xml file where you add the XML configurations for the databases.

Concentrating on the above mentioned points you can reduce the time taken to do the configuration and can get better understanding about the cluster set up that you are implementing.

Tuesday, June 30, 2015

Install and Uninstall MySQL Server in Ubuntu LTS 14.04 Terminal

Installing MySQL Server

Here are the quick steps to download and install MySQL Server in Ubuntu through terminal.

step 1 : Installation
OpenUp a terminal and enter the following command.

sudo apt-get install mysql-server

It will install MySQL server and will ask a password during the process.

You can give a refereed password and re-enter it in the next window.

step 2 : Verification
After the above step MySQL should start automatically. To verify that enter the following command.

sudo netstat -tap | grep mysql

it will show the listening port of the Server and so on.

step 3 : Restarting in case

If the Server is not restarting properly restart the server eneringthe following command.

sudo /etc/init.d/mysql restart

Access MySQL Server

You can access the MySQL server through your terminal by entering following command.

mysql -u root -p

After entering your password the terminal switch into mysql> then you can use that interface to create databases and do other database operations.

Uninstall MySQL Server from Ubuntu

At times you may need to reinstall MySQL Server. For that you need complete removing it from the linux system. Enter the following commands one after the other to completely remove the MySQL Server from the system.

sudo apt-get remove --purge mysql-server mysql-client mysql-common

sudo apt-get autoremove

sudo apt-get autoclean

These will remove the MySQL Server Completely from the system. If you have issues still after these steps remove the mysql directory in the lib folder by running following command.

sudo rm -rf /var/lib/mysql

After that if you want to re install MySQL Server you can follow the above mentioned steps again.

Ting! :)