Each Exchange server with the Mailbox role installed can have one or more mailbox databases, so if you only need to split your database load, you will need to create a mailbox database on the new server and move some mailboxes to it; end of the story. Of course, this means that if a user has a mailbox on ServerA and ServerA goes down, there will be no fault tolerance; users whose mailboxes are on ServerB will be fine, but users with mailboxes on ServerA will not be able to access them.
If you want redundancy, you will need a Database Availability Group; in a DAG, each mailbox database has one or more copies on different servers, only one of which is active at a given moment; if the server where the active copy of a mailbox database resides goes down, another copy will be made active and users will be automatically redirected to it. The down side of this is, you will at least need twice the disk space (because each database will have at least two copies), and some processing power of your servers will be used for data replication.
You also need to take into account that Exchange is not only made by mailbox databases: in order for it to work, you will also need at least an operational server for each of the two other main roles, Hub Transport and Client Access. Hub Transport servers are automatically load balanced and redundant, so you will only need to install the role on the new server and everything will be fine. The same is not true for Client Access: other than installing the role, you will also need to create a Client Access Array in a load-balanced configuration, which needs to be handled at the IP level. Ordinarily you could to that using Windows' built-in Network Load Balancing service, but there's a caveat specific to a two-servers scenario like yours: a Database Availability Group relies on Failover clustering, which is not compatible with Network Load Balancing.
The end result of this is, if you want a fully-redundant setup, you will need two multi-role (Mailbox, Hub Transport, Client Access) servers, a Database Availability Group, a Client Access Array, and an external hardware load balancer, without which you would need to either give up redundancy for the databases or for the Client Access role.
I know you said that you changed the rules to be redirect instead of forward and it didn't resolve the issue; however, redirect is the correct action if you want to preserve the original sender.
What you might want to try is making the redirect change and implementing as transport rules on your hub or edge transports. In fact if you implement on either the hub or edge and it doesn't help you might want to try implementing on the other. Sometimes you will see different behavior depending on whether the transport rule is implemented on the hub or edge transport.
Best Answer
you can configure transport rules on HT, to relay all mails from user1@ to user2@ to be forwarded to user3@
Guide here: http://www.msexchange.org/articles_tutorials/exchange-server-2010/management-administration/using-transport-rules-to-moderate-messages-using-exchange-server-2010.html