Good Day;

i just encountered a similar site to the problem.

This site also has a proxy configured, requiring proxy authentication.

We have an HTTP Operation, with Proxy/Port fields only (Out of the box), with no 'proxy authentication' anywhere.

Has there been a solution to this issue?

Regards;

Anzelem.

Good Day Murray;

Anything to look out for VMs hosting Ensemble Databases on vMware being part of VMware Site Recovery Manager
making use of vSphere Replication? Can it be alone be safely used to boot up the VM on the other site?

Regards;

Anzelem.

If you are certainly sure, you have restarted the instance and the OS space and new size  after startup (as seen in system management) portal don't match, a 'truncate' will release the OS space immediately. I've encountered same issue  and this is what i've done.

Alternatively, you can create your own separate database that you are able to manage yourself and mark the setting of Journal to 'No'. Then map all not so important globals to that DB.

to some extent i concur with the above sentiments. i actually use the old service method, i don't use systemd. e.g perfect use case in cloud environment where you need the instance to automatically start everything if you have an instance stop/start schedule to contain costs. As for Production, i have never implemented a script and prefer a controlled operation. This is mostly because Cache is too finicky when it comes to start-ups, and preferably you need to be present.

Hi Steve;

I have encountered the same problem where these online backups are problematic on a production system - from the time it writes to disk to the time and it's copied out.

To start with - these are cold offsite backups taken only at a point in time - (NOT A DR SOLUTION). So backing up on the DR Async made more sense to us and we relieved the production a lot. I  have actually restored these backups on other aut/training/tests environments and they are just as good.

So if for off-site backup purposes - no harm I have encountered doing that.

Regards;
Anzelem.

Hi Murray;

Have you tested/worked on HCI with VMware and ScaleIO?

Regards;

Anzelem.

Hi Mack;

Can you open your terminal and go and run this command.

%SYS> DO ^mgstat(5,17280,,10)

After at least 20 entries capture the screen shot and post here, for in-depth pointers.

Regards;

Anzelem.

Just been in same situation yesterday and the migrate from ODBC worked for us. We needed the data in Cache for Reports, Dashboards, etc.

The new challenge is: the application that uses MySQL is not yet re-coded to use Cache, so the data is still written in MySQL. Using ODBC to do what we want was giving all sorts of errors... (due to restrictions and limitations for external sources as mentioned in these docs.).  After migrating the data, no issues at all.

Is there a way OR does anyone know how to keep the migrated data always in Sync? If data is written in MySQL it's automatically synced into Cache (... well in Cache speak this will be shadow, mirror, etc). Or custom polling needs to be written?

Regards;

Anzelem.

Thanks Murray for these 'new technology catch-up' articles, especially this part, 9 and 10. Bob alerted me to these. I do have HCI deployment in the horizon based on ESXi and EMC scaleio all-flash (both cache and capacity tiers) architecture. I will keep this in mind when we finally meet the vendors of the HCI kit.

In the article you mentioned "you define the capabilities of storage as policies in vSAN using SPBM; for example "Database" would be different to "Journal". I was hoping to see specific policies for these further down the article??  (well if you consider i'm from traditional arrays where we normally pay attention to these).

Regards;

Anzelem.

I created a separate 'folder' in my outlook so they just go there.

On the positive note, if you see a topic of interest dropping in, it leads you to read it.

Hi Murray;

I agree. For all latest deployments, rather start with single server scaling, and go the ECP way if you really need to. Due to inefficiencies brought about by ECP, or shall I say ECP bottlenecks, we had to get rid of the ECP architecture and rather have a single powerful machine.

Regards;

Anzelem.

Journal route wasn't an option for me. They were just too much and too many to copy (this due to the nature of the application) compared to the smaller one cumulative backup I mentioned. It also depends on whether you are looking at continuous trickling of transactions to the new system or a once off restore.