Yes, you need a server for the secundary database, it could be a new one or an existing one.You can select any region for your secondary server, but it is recommended to use the paired region.
Connections to your existing database will still work and there is no need to change the connection settings in Configuration for that App Service unless a failover is happening, either manual or automatically. In that case the secundary server becomes the primary server and you need to switch connection strings to point at the new primary.
Geo replicaton is covered here and here
Addressing the comments:
Also i have the primary server in a Region North Central US , now is it still safe or does it defeat the purpose to create a new sql server in the same region ? Reason being is that access to the clients would be quicker than lets say creating in Canada
Yes it defeats the purpose. The whole point is that if there is a failure in that region (North Central US) a secondary in that same region will also fail. Sure, clients will need to connect to another region potentially increasing latency but that is still better than no connectivity at all and only temporary until the primary region is restored and fully functional again.
Now North America has several Azure regions, including West US, Central US, South Central US, East Us, and Canada East as per Microsoft documents. So if the primary server is in Central US , I assume it would make sense to put the secondary in one of the regions of North America , maybe South Central US , would that make sense ?
Correct. The paired region North Central US of is South Central US and it is recommended by Microsoft to use the paired region.
[...] If i do then the configuration in my app service has a settings of SRV1 and database as DB1 . If i set the database DB2 as failover does the setting in the config change ? Thats what is confusing me a little. Thanks
Only when a failover takes place you need to update the settings in the config to use the secondary database connection string.
Can you elaborate a bit more on your use case? Have you considered auto-failover groups?