Is it a bad practice to keep Master and Slave (Replica) Database on Same Server? I have a database A (master) on server 1. I need to read from database A perform aggregations and write on database B. Since database A has a very high traffic, I cannot read directly from database A without messing up performance.

Is it a bad practice to keep database A (master) on server 2 and create a server 2 with a read-replica of database A and database B? In other words, I would have a master and a slave database on the same server. Is it OK ?
I would say Yes, it is a bad practice to keep master database in same server than replica database. I have good three(3) reasons why, but there are possible workarounds if you cannot acquire another DB Server. Before I discuss those reasons, have a look at a Pictorial Representation of the InnoDB Architecture (from Percona CTO Vadim Tkachenko)

REASON #1 : Disk I/O
Look at InnoDB's system tablespace file ibdata1. It has lots of moving parts

Data Dictionary
Double Write Buffer (to prepare for crash recovery)
Insert Buffer (manages changes to secondary indexes)
Redo Logs (ib_logfile0,ib_logfile1)
Undo Logs
Rollback Segments

You have to create two different datadir locations. If they reside on the same disk, you will have two ibdata1 files being updated on the same disk, which will suffer increased disk I/O and will slow down both MySQL instances.
Suggestion #1: You could accommodate this having the datadir of each MySQL Instance on a different disk using its own disk controller (Make sure your disk controllers have up-to-date kernels).
This is the same concept you would apply if

You use Amazon MySQL RDS, having a Master and Slave in different availability zones
You have VMWare, having Master VM and Slave VM live on different disks

REASON #2 : RAM
Look back at the InnoDB Buffer Pool. You will have two of them. If you set these too large, you could trigger some swapping in the OS.
Suggestion #2: If the Slave instance is just for aggregation (or aggrevation), you could tune the Slave's my.cnf to use a lot less memory (Smaller Buffer Pool, Smaller MyISAM Key Buffer)
Suggestion #3: Increase RAM
REASON #3 : Data Redundancy / High Availability
If mysqld goes down on the Master, you have mysqld for the Slave still running. What if you have a hardware failure and the database is mission critical ? There is nowhere to failover.
Suggestion #4: You should get a cheap server with the same amount of disk and half the memory of of the Master and configure a Slave.
Suggestion #5: If you applied Suggestion #1, you could move the disk holding the Master to another machine. If that disk is fried, you have the disk holding the Slave. Hopefully, the one DB Server did not having a real disaster and and damage both Master and Slave disks.