Connect Existing DB Server to Brand New App Server

Has anyone had to create a new V11 (or really any version) application server and connect it to an existing SQL Database server? Assume we don't have access to the old app server (although we might).

I have some ideas, but I'd like to know how others have gone about it, particularly in terms of folder recreation. I figure it's no problem to connect them using the console once the app server is completed, but the creation of a new PILOT/PROD folder is a little bit of a fuzzy area to me, considering that it would normally create the SQL schemas & tables, which I fear might override my existing data. 

Follow up question- any other issues you ran into?

Thanks!

Parents
  • If you connect to the existing database server and use a new database during the console setup/creation process you won't overwrite anything in the old database. Everything will exist in the new database. 

  • And so after that, and subsequent folder creation, would I do a backup of the old DB and restore over the new one? The idea is to continue use of the old DB as if nothing had ever happened. I probably should have mentioned this was a DR scenario, not just trying to repurpose an old machine.

  • Ah, ok.. that's completely different. The point I made earlier would not be correct for you in this context. If you want a proper DR solution it's tough to develop in this online format given all the variables involved, but there are some things I can mention that might stimulate some discussion for you. There are multiple levels of redundancy you need to consider. Each microservice (runtime process server(s), Syracuse server, etc...) could be included in your recovery plan, along with your data that exists in mongo DB, SQL Server (or Oracle). For example, at the data level, designing your point in time recovery scenario will change based on the granularity of data you consider volatile. Meaning, if you need up to the minute recovery that's a different level solution than up to the hour, or up to the day. If you are using system snapshots from a hosted environment then that is completely different than a non-hosted solution. If you want a lower budget solution SVG backups allow you to import your folder into a solution.

Reply
  • Ah, ok.. that's completely different. The point I made earlier would not be correct for you in this context. If you want a proper DR solution it's tough to develop in this online format given all the variables involved, but there are some things I can mention that might stimulate some discussion for you. There are multiple levels of redundancy you need to consider. Each microservice (runtime process server(s), Syracuse server, etc...) could be included in your recovery plan, along with your data that exists in mongo DB, SQL Server (or Oracle). For example, at the data level, designing your point in time recovery scenario will change based on the granularity of data you consider volatile. Meaning, if you need up to the minute recovery that's a different level solution than up to the hour, or up to the day. If you are using system snapshots from a hosted environment then that is completely different than a non-hosted solution. If you want a lower budget solution SVG backups allow you to import your folder into a solution.

Children
  • Ha, yeah, this is more of an actual live fire exercise than a DR design challenge. Ideally, we would have backed up all that stuff, but for this hypothetical, let's say we did not, and ONLY have the SQL server.

    Mongo is another story completely- we'll have to start from scratch on that (fortunately I don't think it's a lot to recreate). 

    About the folder- in my imagination, we would create a NEW Database on the same SQL instance and create the PILOT & PROD folders as we would with a new installation, then take a backup of the old database and restore it on top of the new one we just created. Does that sound feasible, or is there a better way to hitch that existing data to a new app?

    Just FYI, the complete backups DO exist, they just may not be available as quickly as this partial rebuild we're planning, assuming we succeed.

  • There is a symbiotic link between the application folder on disk and the database server. If they are desynchronized it isn't good. You need to solve that symbiotic connection in your live fire exercise to be sure that when you revalidate a table your physical table structure remains consistent when compared to the logical structure described in the *.fde and *.srf files located in the Folders\PILOT\FIL directory. For me, I think the approach to restore part of the data (database only) carries with it some risk. 

  • So I'm receiving some good news from this very not-hypothetical customer, but it is an interesting point you raise about the synchronization between App and SQL. Now I can ask the question I guess scared me at the start of the thread- CAN one theoretically restore a company's Sage environment using ONLY SQL, or do the lack of app server files disqualify us?