I am planning an enterprise deployment with SiteCore 6.5....
I am thinking to have one instance of CMS (WebAuthoring) and several servers as Content Delivery...
I was thinking to replicate the Core Database between the Content Delivery and the WebAuthoring instances... and I was not able to understand the role of the LinkDatabase... Do I need the linkdatabase on the Content Delivery?!
I was also considering an alternative scenario without the CORE database for the content delivery, in this case, I should put the LinkDatabase on the web database, shall I have in place a procedure to rebuild the LinkDatabase or it is completely useless in a content delivery scenario??? I really cannot understand from the documentation the purpose of the link database and the API that use it.
pls let me know your opinion and thoughts about it.
From what I can tell you don't have to have a LinkDatabase on content delivery nodes. It is however quite handy as it is one of the fastest ways to get a list of references and/or referrers for a specific item.
You can point the LinkdDatabase at the web database and Sitecore will automatically keep it updated for you as described in section 3.6.1 of the Scaling Guide:
You can use the Sitecore link database API to access all the items
that are referenced by or refer to a specific Sitecore item.
All the link database information is stored in the Core database by
default, and aggregates data for the items from every Sitecore content
database.
You configure the location of the link database in the web.config in
the Link Database section file in the connectionStringName parameter:
<!-- LINK DATABASE -->
<LinkDatabase type="Sitecore.Data.$(database).$(database)LinkDatabase, Sitecore.Kernel">
<param connectionStringName="core" />
</LinkDatabase>
In a single-server Sitecore setup, the link database is automatically
updated.
In a multi-server Sitecore setup, the link database is only
automatically updated for databases that are referenced from the CM
environment.
To ensure that Sitecore automatically updates the link database in the
CD environment:
The CD and CM instances must use the same name to refer to the publishing target database across the environments (typically Web).
One of the following conditions should be met:
The Core database should be shared or replicated between the CM and CD instances.
The Link database data should be configured to be stored in a database which is shared between CM and CD publishing target database
(typically Web).
If you want to remove the core database from the content delivery nodes there is a section called 'Remove the Core database from the content delivery environment' in the Configuring Production Environments(PDF) document.
The Link database keeps track of relations between items, such as item <-> template relations. It's required for Sitecore and possibly for your custom components so they can do fast lookups for those kind of relations.
If the databases are not physically on a different machine, i would just go for a shared Core db where all the servers use the same core.
If they are on different machines, then go for a seperate Core with SQL replication.
The scenario without Core is possible, but not recommended because it's more difficult to setup and to maintain.
Related
I have created a lot of different instances of TYPO3 versions and have not cleverly named my databases. Is there a way to find out which databse I am using with my current project (TYPO3 v9.5.12)?
If you're an Admin/System Maintainer, you can open the TYPO3 backend module "Environment". The first module card "Environment Overview" will give you the name of the currently used database, among some other information.
As an alternative, you can open /typo3conf/LocalConfiguration.php, where the current database is configured. There you could also change the database, if needed.
I like the idea that third part apps run at *.github.io *.shopify.com *.volusion.com works, people make own pages (modify/use template), and host inside.
I'm interested in architecture, how all of this happen?
Do they save files in disk, or write inside database
How easily manage dynamic subdomains?
What happens behind the scene?
What language they use?
This is called multitenancy. It can be achieved in a number of ways with on many different server platforms. There are a number of pieces, for example:
URL rewriting rules handled at the load balancer or web server level to let *.site.com act as site.com/users, or something to that effect depending on your platform architecture
A database of tenants (users) and their associated account names or subdomains
Routing or resolution code that conditionally switches the database connection (or tables, or security modifiers, etc.) per request based on the calling tenant
Ultimately, a tenant is just a row in a database table somewhere, and the application is written in a generic way so that each tenant uses the same "base" code. How that works and how it is implemented can vary greatly between applications.
Update: Per your comment, here are some resources specifically dealing with tenancy in ASP.NET:
Simple Multitenancy With ASP.NET MVC 4
Developing Multi-tenant Applications for the Cloud, 3rd Edition (free Microsoft ebook)
ASP.NET MVC 5, Entity Framework, Ninject and Multi Tenancy Setup
Multi-tenancy in ASP.NET MVC
I work at a large university and have been instructed to look in to using a source control system (git, svn, etc) to manage the websites. We use Joomla which relies heavily on MySQL.
Currently, we have a barely functional system that uses a development server which pushes to a live server whenever we change a website. It's a pain and it doesn't always work. Plus, we can and often do overwrite changes that another dev has made.
We want to be able to manage content via the Joomla front end on the dev branch, then push those changes to the test branch, then to the master (live) branch.
Without getting off in tot he weeds: my question is, essentially, what is a good strategy for managing websites using a CMS like Joomla that relies on a database?
Since you also want to sync the database (content is stored in the db, while images and media are on the filesystem), you need the commit/push script to also dump the db to a file, and the pull script to load the db. This can be done with pre and post hooks, http://githooks.com/ or google it.
However there will be different parts of Joomla that you will want to sync separately.
Let's consider three servers:
edit server: where content is managed
dev server: where extensions are tested and configured
test server
production server
Let's consider three layers of information:
The user and session data: this should not be synchronized at all so people are not logged out, and if any users register on the production server their login will be preserved.
The contents, user groups and assets (privileges): this is the articles, news, images which have to go from edit to test to production and to dev (unless you have content-specific privileges at the user level i.e. each user has separate privileges on each content item)
The template, extensions, modules, menu configurations: this will go from dev to test to production and edit.
Each of these groups of data will require their own branch and their custom pre-commit hooks to include in the commit/push the relevant database tables. The list of tables for each group depends on the extensions you are using.
I have written an article it's in italian and for svn but you can grab some of the bash scripts we use: http://www.fasterjoomla.com/joomla-tips/svn-per-joomla or translated by google http://translate.google.com/translate?sl=it&tl=en&js=n&prev=_t&hl=it&ie=UTF-8&u=http%3A%2F%2Fwww.fasterjoomla.com%2Fjoomla-tips%2Fsvn-per-joomla
I have a Drupal site running in production. After some time I had changes in code and through admin as well, some configurations, changed content types and changed body of some pages etc. Meanwhile the production database was growing. Now I want my changes in production by not loosing the data which is already in production DB. One way is to repeat the same steps as of Dev on production. That looks not good to me. Is there any automated procedure to migrate the changes?
Thanks
The modules features and strongarm will do the trick for you.
Features can help you save and migrate the content types, for example, while strongarm will help you migrate site settings and configuration information that is stored in variables.
After installing the two modules, go to Admin --> Structure --> Features --> Manage on your dev site and create features for the changes you want to transfer from dev to production. If you have both features and strongarm installed, it will let you create features that capture both site building components (content types, views you created, roles and permissions you have changed, etc) and site settings (settings stored in variables -- you'll see the long list of settings you can export once you install the strongarm module). When you create your feature, it is exported as code (as a module), and you can then add that module to any additional sites in which you want to add the components you selected when creating your feature(s).
You will have to install the two modules on your production environment too. Then add the features you just created in your dev environment to your production site. Once set up though, you can transfer changes between dev and production environments more easily going forward!
Here is the features documentation: http://drupal.org/node/580026.
Hope this doesn't sound too confusing!
I am working on an application which acts as a setup box for other child applications. I want to set up child applications from one central parent application. Set up includes database setup (db:create and db:migrate), subdomain set up etc for child apps.
This is going to work like this: a Subscriber will subscribe many applications. On subscription the application will be configured to work on subscribers provided subdomain (on my site). Every instance of a subscribed application will have its own database. So I need to set up database for each subscriber, and domain name too.
Currently I am creating database based on child application subdomain, using ActiveRecord::Base.connection.execute.
After creation of the database I want to load the schema of the child app to the database created. For this I had posted a question here
schema.sql not creating even after setting schema_format = :sql
Is there any good efficient method/approach that will help me?
Also I am a bit confused about subdomaining how its gonna be work?
Any help/thought appreciated...
Thanks,
Pravin
Since there is no real need for a separate database for each user and for each 'app', you may want to check out a term called multi tenant.
Also, subdomains can be handled in rails 3 and use something called Devise for User authentication. Github has a rails 3 sudomain devise authentication fork to get you started.
Until you really see a need for all these databases, keep it simple. One database per application, and connect to each application via Active Resource.
Be warned, that what you are undertaking can confuse even a hardened app builder, so i hope your experience begets that of which your current Stackoverflow rate is at.
All the best.